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1.  INTRODUCTION 

When  we  send  electronic  mail,  funds,  or  programs  to  another  site,  we  expect  many  things  to 
happen:  the  message  should  be  delivered  to  a  particular  site  and  not  to  others;  only  one  copy  of  the 
message  should  be  delivered;  the  delivery  should  be  timely;  the  receipt  should  be  acknowledged;  and 
so  on.  In  computer  science  terms,  these  properties  are  often  called  safety  (correct  delivery),  liveness 
(effective  work  being  done),  and  performance  (work  being  done  fast  enough).  The  social  importance 
of  guaranteeing  these  properties  for  electronic  media  cannot  be  over-valued:  our  dependence  on 
such  systems  increases  daily. 

Over  the  past  few  years,  the  Internetwork  Concepts  Research  project  at  ISI  has  been  studying  the 
overall  problem  of  protocol  verification,  as  well  as  the  design  of  correct  protocols.  Simultaneously, 
the  ISI  Program  Verification  project  has  been  developing  a  general-purpose  specification  and 
verification  system  called  Affirm.  This  report  presents  the  results  of  joint  research  over  a  year’s  time. 
Specific  accomplishments  include  increased  understanding  of  an  underlying  formalism  (state 
transition  models),  rendering  of  such  models  in  the  specification  language  of  Affirm,  experimenting 
with  various  ways  of  expressing  the  three  properties  mentioned  above  so  that  they  can  be  proved  for 
state  transition  specifications,  study  of  several  levels  of  specification  (all  the  way  from  the  user 
services  down  to  the  programming  language  implementation),  an  in-depth  study  of  a  particular 
protocol  (the  Alternating  Bit  protocol),  and  a  survey  of  a  number  of  other  protocols.  Our  overall 
accomplishment  is  a  general  method  of  specifying  and  verifying  certain  aspects  of  protocols, 
supported  by  mechanical  assistance.  Most  of  our  work  has  focused  on  safety  properties,  rather  than 
liveness  and  performance  properties. 

Because  we  expect  at  least  one  of  the  three  areas  of  communication  protocols,  state  transition 
machines,  and  abstract  data  types  to  be  new  to  most  readers,  we  have  included  an  introduction  to 
each  of  these  topics  in  this  chapter.  The  main  bulk  of  the  report  presents  a  rather  simple  example  of 
the  integration  of  these  concepts.  Thus  the  emphasis  is  on  methodology  rather  than  the  results 
obtained  for  a  particular  protocol.  Later  work  [42]  will  present  extensive  concrete  results  on 
protocols  of  more  practical  interest. 

Our  general  method  of  protocol  specification  and  verification  is  summarized  in  Chapter  2.  Details 
of  the  specification  method  are  illustrated  in  Chapter  3.  Verification  issues  are  considered  in  Chapter 
4.  The  method  is  applied  to  the  Alternating  Bit  protocol  in  Chapter  5.  Chapter  6  summarizes  some  of 
the  results  obtained  with  more  complex  protocols.  Extensions  and  problems  are  analysed  in  Chapter 
7.  Our  conclusions  are  presented  in  Chapter  8. 
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INTRODUCTION 


1.1.  State  Transition  Models 

A  variety  of  methods  for  modeling  the  behavior  of  systems  in  terms  of  state  transitions  have  been 
developed,  including  finite  state  automata  (FSA)  and  abstract  machines.  The  key  components  of 
these  models  are  as  follows. 

1 .  A  set  of  commands  (also  called  inputs  or  events). 

2.  One  or  more  state  variables,  collectively  called  the  state. 

3.  A  transition  function 

(command  X  state)  -»  state. 

4.  An  initial  state  (assigning  initial  values  to  all  the  state  variables). 

Each  command  is  a  single  state  transition  function  mapping  the  current  state  into  a  new  state. 
Generally,  commands  are  considered  atomic  operations  that  are  processed  sequentially:  no 
concurrent  commands  are  allowed. 

A  state  transition  machine  operates  by  starting  in  its  initial  state.  At  unspecified  times,  the  state  is 
transformed  by  one  of  the  state  transition  functions  (or  an  input  "appears,"  and  is  used  by  the  overall 
transition  function  to  effect  a  state  change).  The  machine  may  be  designed  to  operate  forever,  or  may 
have  a  specified  set  of  final  states.  When  one  of  these  states  is  reached  the  machine  is  considered  to 
have  halted. 

Within  these  basic  guidelines,  there  are  a  number  of  possible  variations.  State  variables  may  be 
defined  as  value-returning  functions.  The  commands  may  have  parameters.  The  effects  of 
commands  may  be  made  visible  to  the  outside  world  (i.e.,  the  users  of  the  machine)  by  defining  some 
of  the  state  variables  to  be  visible,  or  by  producing  explicit  outputs  as  additional  effects  of  an 
operation.  Exceptional  conditions  may  be  specified  where  a  given  command  has  no  effect  on  the 
state  of  the  system  except  to  produce  an  error  indication  or  output  to  the  invoking  user.  If  the  data 
types  of  the  state  variables  are  unbounded  (e  g.,  a  queue),  the  model  may  not  have  a  finite  number  of 
states. 

State  transition  models  are  often  written  graphically,  with  circles  representing  states  and  arcs 
representing  transitions.  Each  arc  is  labeled  with  the  command  causing  the  transition.  Outputs 
produced  are  also  written  on  the  arcs  if  needed.  Fig.  1-1  gives  an  example  of  a  state  transition  model 
for  a  very  simple  message  system  allowing  only  a  single  message  in  transit  from  sender  to  receiver. 
(This  example  is  explained  further  in  Chapter  3.) 


SPECIFICATION  AND  VERIFICATION  IN  AFFIRM 


3 


InitializeService 


Figu  re  1  ■  1 :  A  simple  message  system 

1.2.  Specification  and  Verification  in  Affirm 
Affirm  [31 , 9, 50]  is  an  experimental  system  for  the  algebraic  specification  and  verification  of  user- 
defined  abstract  data  types.  The  heart  of  the  system  is  a  natural  deduction  theorem  prover  for  the 
interactive  proof  of  data  type  properties.  (These  properties  are  stated  in  the  predicate  calculus 
extended  wi  i  data  types.)  Programs,  written  in  a  variant  of  Pascal  extended  with  data  types,  may  be 
verified  using  the  inductive  assertion  method  [8].  Additional  features  include  tools  for  the  analysis  of 
algebraic  specifications,  a  library  of  useful  data  types,  and  user  interface  facilities.  Experience 
includes  extensive  experimentation  with  data  type  specifications,  verification  of  small  programs,  the 
specification  and  partial  proof  of  a  large  file-updating  module,  and  the  proof  of  high-level  properties 
of  protocols  and  security  kernels. 

The  specification  and  theorem-proving  portions  of  Affirm  are  relevant  to  the  current  discussion. 

1 .2.1 .  Data  Abstraction 

As  Guttag  has  explained  [14, 15, 16],  a  data  type  is  specified  by  first  defining  three  sets  of 
functions: 

1.  Constructors.  These  functions  create  values  of  the  type.  Their  range  is  the  data  type  being 
specified.  All  values  of  the  type  can  be  described  in  terms  of  a  some  functional  composition  of 
these  functions. 
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2.  Extenders  (or  Modifiers).  These  functions  also  have  the  data  type  being  specified  as  their 
range,  but  in  contrast  to  the  constructors,  they  are  not  needed  to  express  values  of  the  data 
type.  (These  functions  can  be  expressed  in  terms  of  the  constructors.) 

3.  Selectors  (or  Predicates).  These  functions  yield  values  of  types  other  than  the  one  being 
specified.  The  general  term  is  selector,  but  functions  yielding  values  of  type  Boolean  are  often 
termed  predicates. 

For  example,  the  constructors  of  a  queue  are  NewQueue  (the  empty  queue)  and  Add  (appends  an 
element  to  a  queue).  Example  extender  functions  are  Remove  (deletes  the  first  element  from  a 
queue)  and  Append  (concatenates  two  queues).  Example  selector  functions  are  Front  and  Length. 
Example  predicates  are  in  and  nodups  (asks  whether  there  are  any  duplicate  elements). 

declare  q.  ql ,  q2:  QueueOflnteger, 
declare  i:  Integer; 

interfacea  NewOueueOf  Integer,  q  Add  i,  Remove(q),  Append(q1,  q2):  QueueOflnteger; 
interfaces  Front(q).  Length(q):  Integer; 
interface  i  in  q:  Boolean; 


The  effect  of  such  a  specification  is  to  view  values  of  the  type  in  terms  of  the  constructors  that  build 
them.  All  selectors  and  extenders  are  defined  in  terms  of  these  constructors.  For  example,  the  queue 
of  integers 
<1, 2, 3> 

is  represented  (in  infix  form)  as 

((NewQueueOflnteger  Add  1)  Add  2)  Add  3 

Thus  the  first  part  of  a  specification  gives  the  names  of  all  operations,  their  domains,  and  their 
ranges  (e.g.,  the  syntax  of  the  type). 


The  second  part  of  a  data  type  specification  provides  semantics  for  the  operations.  Extenders  and 
selectors  are  defined  by  equational  axioms  relating  how  each  function  behaves  when  applied  to  each 
of  the  constructors.  (Constructor  functions  are  treated  as  primitive,  unspecified  operations.)  These 
axioms  look  like  equations  but  are  treated  by  Affirm  as  left-to-right  rewriting  rules.  Various  methods 
are  used  to  check  the  consistency  and  completeness  of  the  axioms  [30, 31).  For  example,  some 

axioms  from  the  type  QueueOflnteger  are: 
axioms 

Remove(NewQueueOflnteger)  *  =  NewQueueOflnteger, 

Remove(q  Add  i)  *  «  if  q  «  NewQueueOflnteger 
then  q 

else  Remove<q)  Add  I, 
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L«ngth(NewQueueOflnteger)  «  ■  0, 

Lengthfa  Add  i)  ■  *  Length(q)  +  1; 

Append(q.  NewQueueOf Integer)  *  =  q. 

Append(q1,  q2  Add  i)  =  *  Append(q1 ,  q2)  Add  i, 

An  important  use  of  these  data  type  specifications  is  to  obtain  levels  of  abstraction,  in  particular,  to 
avoid  low-level  implementation  details.  For  example,  in  our  specification  of  a  queue  we  don't  care 
whether  it  is  implemented  with  an  array  or  via  pointers  and  a  linked  list.  Of  course,  implementation 
details  dfl  constrain  the  abstraction,  e.g.,  by  space  limitations,  but  this  is  a  separate  problem.  A 
standard  method  for  relating  implementations  to  their  abstractions  is  the  representation  (or 
abstraction)  function  rep  mapping  from  implementation  to  abstraction  [22, 52].  For  example,  we 
might  define  a  function 

rep(a,  lb,  ub)  =  =  if  lb  >  ub 

then  NewQueue 

else  rep( a,  lb,  ub-1)  Add  a[ub] 

to  map  from  an  array  a  over  the  sequence  of  (integer)  indices  lb  to  ub  into  queues. 

The  proof  of  correctness  for  an  implementation  involves  showing  that  all  abstract  operations  of 
interest  have  code  that  computes,  via  the  rep  function,  the  proper  function.  For  example,  we  might 
have  a  procedure 

procedure  Removelmplementationfvar  a:  Array;  var  lb,  ub:  Integer); 
pre  wf(a,  lb,  ub); 

post  wf(a.  lb,  ub)  and  rep( a,  lb,  ub)  «  Remove(rep(a’,  lb’,  ub’)) 

...  body  of  procedure ... 

where  the  primed  notation  x'  denotes  the  initial  value  of  x  at  the  start  of  the  procedure.  The 
expression  "wf(a,  lb,  ub)"  is  the  implementation  (or  concrete )  invariant  well-formed,  a  predicate 
showing  that  the  variables  of  the  implementation  will  always  map  into  some  abstract  object.  In  the 
inductive  assertion  method,  the  interpretation  of  the  Qrg  and  post  conditions  is  as  follows.  If  the 
precondition  holds  for  the  variables  at  entry  to  the  procedure,  then  the  postcondition  will  hold  for  the 
variables  at  procedure  exit.  Note  that  there  is  no  statement  that  the  procedure  terminates. 

1.2.2.  Theorem  Proving 

Typical  data  type  properties  might  include  “the  length  of  the  concatenation  of  two  queues  is  the 
sum  of  their  lengths,"  stated  as 

Length(q1  Append  q2)  =  Length(ql)  +  Length(q2) 
and  "The  length  of  any  queue  is  always  nonnegative” : 

Length(q)  >  0 
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Such  properties  are  proved  by  induction  based  on  the  constructors  of  the  data  type,  that  is,  using 
structural  induction.  For  our  queue  example,  the  induction  schema  uses  the  inference  rule 

PfNewQueueOflnteoer),  (all  a.  i  (P(a)  D  P(o  Add  i))) 

(all  q  (P(q))) 

In  other  words,  we  prove  the  property  P  for  NewQueueOflnteger  and  then,  assuming  it  for  some 
queue  q,  prove  P  for  q  with  any  element  i  appended  to  it  (q  Add  /).  These  two  proofs  suffice  to  prove 
P  for  all  q. 

Affirm 's  style  of  theorem  proving  is  interactive.  The  user  develops  the  proof;  the  system’s  role  is 
to  follow  the  user’s  commands  and  provide  various  kinds  of  necessary  information  and  checking.  It 
does  not  attempt  to  search  for  a  proof.  Affirm  simplifies  propositions  using  the  data  type  axioms  (as 
rewrite  rules),  with  built-in  simplification  procedures  for  the  predicate  calculus.  The  user  can  ask  the 
system  to  employ  induction,  split  into  subgoals,  substitute  equalities,  and  apply  lemmas; 
experimentation  with  various  strategies  is  often  necessary  before  finding  a  proof.  This 
experimentation  and  backtracking  is  supported  with  a  model  of  the  proof  as  a  forest  oi  proof  trees, 
and  with  numerous  display  and  query  features. 

The  overall  effect  is  that  the  user  follows  the  usual  mathematical  proof  methods,  but  Affirm  carries 
out  the  mechanics  of  the  proof  (down  to  the  axioms  or  assumptions).  Of  course,  proofs  are  not 
ironclad:  there  might  be  a  bug  (in  either  our  code  or  the  underlying  Interlisp  system),1  or  the  user 
might  make  an  invalid  assumption.  Affirm  is  used  to  produce  better,  not  guaranteed  perfect,  proofs. 
Such  proofs  should  also  be  readable  (when  properly  structured  in  terms  of  lemmas)  and  read  to  be 
believed. 

A  more  serious  problem  is  that  of  ascertaining  that  we  have  proved  (or  are  trying  to  prove)  what  we 
really  want  proven.  Experience  has  shown  repeatedly  that  propositions  we  thought  were  theorems 
were  nol;  this  quickly  led  us  to  the  conclusion  that  "the  purpose  of  proving  (with  Affirm)  is  to  turn  a 
conjecture  into  a  theorem." 


Vo  our  knowledge,  Affirm  has  never  generated  an  invalid  proof:  we  consider  it  unlikely  that  an  error  would  produce  just 
the  right  behavior  to  validate  an  incorrect  theorem,  particularly  since  the  user  would  probably  note  associated  strange 
behavior.  The  usual  result  of  a  bug  is  to  prevent  a  valid  proof  from  proceeding.  However,  soundness  cannot  be  guaranteed. 
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1.3.  Protocols 

In  order  to  apply  state  transition  models  and  abstract  data  types  to  communication  protocols,  we 
must  first  understand  specification  and  verification  problems  in  the  protocol  domain.  The  meaning  of 
protocol  specification  and  verification  will  be  described  in  terms  of  a  model  first  introduced  in  [47]. 

1.3.1.  Protocol  Specification 

A  user’s  interest  in  a  protocol  lies  in  what  kind  of  services  it  provides.  Usually  the  service  involves 
interactions  with  other  entities  (such  as  users  or  programs)  in  order  to  get  certain  functions 
performed.  For  example,  one  user  may  wish  to  interact  with  another  (remote)  user  by  performing 
various  functions  such  as  SendMessage.  How  these  functions  are  actually  performed  by  the  protocol 
is  not  really  of  concern;  only  the  end  result  matters. 

Users,  then,  can  regard  the  protocol  as  a  black  box,  to  which  one  gives  a  series  of  commands  in 
order  to  get  certain  services  performed.  The  description  of  this  machine  is  termed  the  service 
specification.  One  theorem  we  may  wish  to  prove  about  a  service  specification  is  that  the  messages 
received  constitute  an  initial  subsequence  of  the  messages  sent  (i.e.,  messages  are  not  delivered  in 
the  wrong  order,  or  garbled,  nor  are  messages  spontaneously  delivered  if  they  were  not  sent). 

In  general,  the  components  used  to  provide  the  service  can  also  be  regarded  as  black  boxes  in 
their  own  right.  In  the  case  of  protocols  there  is  always  more  than  one  entity  interacting  (because  we 
are  dealing  with  distributed  systems).  In  order  to  provide  a  given  service,  it  is  necessary  to  have 
several  stations  (at  least  one  for  each  physical  site)  interacting  with  each  other  via  some  transmission 
machine  (see  Fig.  1-2).  The  pattern  of  their  interactions  constitutes  the  protocol. 

This  transmission  machine  is  just  another  level  of  protocol.  Thus  we  can  see  a  hierarchy  of 
abstract  machines  developing.  In  this  uses  hierarchy  (following  Parnas  [36]),  each  protocol  level 
makes  use  of  the  services  provided  by  the  lower  level.  Within  each  level,  there  is  an  implementation 
hierarchy  where  the  service  is  logically  implemented  by  the  abstract  protocol  specification.  The 
protocol  is  implemented  in  turn  by  an  actual  program.  Thus  for  each  protocol  level  N,  the  following 
information  must  be  provided: 

1.  A  service  specification,  describing  the  services  provided  by  the  level  to  the  users  above,  at  level 
N  +  1; 

2.  A  protocol  specification,  describing  the  interaction  of  the  objects  in  this  level  in  a  precise  way 
(assuming  services  provided  by  the  level  below,  level  N  - 1);  and 

3.  A  program  implementing  each  station  in  the  level  (of  course,  the  program  may  vary  from  station 
to  station). 
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Figure  1  -2:  The  internal  structure  of  the  service  machine 

This  characterization  follows  closely  the  model  for  open  system  interconnection  being  proposed  by 
the  International  Organization  for  Standardization  [23]. 

1.3.2.  Protocol  Verification 

In  the  context  of  the  model  introduced  in  the  previous  subsection,  we  say  that  protocol  verification 
is  a  formal  demonstration  that  the  logical  design  of  the  protocol  (the  interaction  of  the  stations  within 
one  layer)  satisfies  the  service  specification  of  that  layer. 

Note  that  this  will  depend  on  the  assumed  properties  (the  service  specification)  of  the  layer  below. 

The  ultimate  task  in  protocol  verification  is  to  demonstrate  that  an  actual  program  is  a  valid 
implementation  of  the  protocol  specification.  That  is,  when  one  has  reached  a  low  enough  level  of 
abstraction  in  the  specification,  it  is  possible  to  take  an  actual  program  that  purportedly  implements 
the  protocol,  and  show  that  it  is  correct  with  respect  to  the  specification.  This  is  no  different  from 
traditional  program  verification. 

In  order  to  gain  greater  confidence  that  specifications  are  suitable  for  their  intended  use,  it  is  useful 
to  prove  properties  of  a  single  specification.  For  example,  we  might  want  to  show  that  the  sequence 
of  messages  delivered  is  equal  to  the  sequence  of  messages  sent.  Liveness  properties  such  as 
freedom  from  deadlock  or  eventual  termination  are  also  often  proved  for  a  single  specification.  We 
will  discuss  these  issues  at  greater  length  in  Section  3.6. 
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Thus  we  have  three  maior  types  of  protocol  verification  problems  in  each  layer  of  a  system: 

1 .  Verification  of  the  protocol  against  its  service ; 

2.  Verification  of  an  implementation  against  the  protocol ;  and 

3.  Independent  verification  of  desired  properties  of  the  service,  protocol,  and  program. 

1.4.  Related  Work 

To  our  knowledge,  this  work  is  the  first  combination  of  state  transition  machine,  protocol,  and 
axiomatic  specification  notions.  However,  a  large  body  of  work  exists  in  each  of  these  areas 
individually,  and  to  a  lesser  extent  for  each  pair. 

A  variety  of  methods  have  been  used  to  specify  communication  protocols,  including  Petri  nets  (and 
related  graph  models),  formal  languages,  sequencing  expressions,  I/O  histories,  and  programming 
languages.  However,  the  variations  on  state  transition  machine  methods  discussed  in  Section  1 .1 
seem  to  be  most  popular.  Much  of  this  work  is  either  limited  in  expressive  power  (e.g.,  finite  state 
automata)  or  lacking  a  solid  theory  and  automated  tools  for  verification.  Sunshine  [48]  provides  a 
survey  and  comparison  of  this  work. 

In  the  area  of  abstract  data  types,  a  large  body  of  work  also  exists  [14, 15, 10, 1 1 ,  28].  Usually  state 
transition  machine  (or  abstract  machine)  model  approaches  and  axiomatic  approaches  are  viewed  as 
mutually  exclusive  alternatives  [18, 4, 26].  A  number  of  state  transition  machine  models  have  been 
proposed  [34, 39, 37, 4, 38,  27].  Several  variations  of  axiomatic  methods  have  also  been  developed 
[16, 25, 12].  The  notion  of  specifying  state  transition  machines  axiomatically  seems  relatively 
unexplored,  although  Flon  and  Misra  [7]  hint  at  it. 

We  have  drawn  heavily  on  the  following  concepts: 

-  Hierarchical  layering  and  cooperating  remote  stations  within  a  layer  from  the  protocol  domain 
[47,  23]; 

-  Verification  of  the  properties  of  a  specification  [15, 18,  32,  38, 6, 19,  20, 35];  and 

•  Verification  that  a  lower  level  system  properly  implements  a  higher  level  one  [40,  37, 17, 13],  or 
that  the  two  systems  are  behaviorallv  equivalent  [4, 45]. 

Of  course,  we  have  had  to  adapt  these  concepts  to  the  new  environment  resulting  from  the  merger  of 
protocol,  state  transition  machine,  and  axiomatic  specification  concerns. 
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2.  AN  OVERVIEW  OF  OUR  METHOD  OF  PROTOCOL 
SPECIFICATION  AND  VERIFICATION 

Our  method  of  specifying  and  verifying  protocols  can  be  summarized  as  follows: 

1.  Produce  a  service  specification.  If  a  state  transition  machine  description  of  the  service  already 
exists,  translate  it  into  an  Affirm  representation.  Otherwise  directly  state  the  service 
specification  as  a  state  transition  specification  in  Affirm. 

2.  Validate  that  the  service  specification  at  least  partially  meets  the  requirements  of  the  user 
(either  the  ultimate  user  or  another  layer).  Typically  this  involves  proving  some  invariant 
properties  of  the  specification,  e.g.,  what  gets  sent  by  the  user  at  one  station  gets  delivered  to 
the  user  at  the  other  station  in  the  same  order. 

3.  Produce  the  protocol  specification.  Again,  if  a  state  transition  machine  representation  exists, 
simply  translate  it  into  an  Affirm  representation. 

4.  Verify  that  the  protocol  specification  implements  the  service  specification.  This  is  a  two-step 
process. 

a.  First,  define  a  correspondence  (a  rep  function)  between  the  state  variables  of  the  two 
specifications. 

b.  Then  show  that  the  axioms  of  the  service  specification,  when  reformulated  using  the 
corresponding  data  structures  of  the  protocol  specification,  are  theorems  provable  from 
the  axioms  of  the  protocol  specification. 

A  further  validation  involves  independently  stating  the  service  requirements  in  terms  of  the  state 
variables  of  the  protocol  specification,  and  then  proving  that  the  protocol  specification  satisfies 
these  requirements. 

5.  Specify  an  algorithm  implementing  the  protocol  specification. 

6.  Verify  that  the  algorithm  implements  the  protocol. 


Chapters  3,  4,  and  5  discuss  these  steps  in  some  detail.  Figure  2-1  displays  the  relationship  of  the 
elements  involved  in  protocol  specification  and  verification. 
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(§3.3,  4.1) 

Service  (§3.l-§3.5)  - *  Date  Transfer  Property  (§3.6) 

|  (§4.2.  §5.4) 

Protocol  (§6.  l-§6.3) - *  Transformed  Data  Transfer  Property  (§5.5) 

j<§4.3) 

Program  (§6.6) 

Figure  2-1 :  The  steps  in  protocol  verification 

The  references  prefaced  by  "§"  are  pointers  to  relevant  sections  of  this  paper 
Vertical  lines  mean  Implamantad  by; 

Horizontal  lines  mean  Invariant  of. 
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3.  A  SERVICE  SPECIFICATION  FOR  A  SIMPLE 
MESSAGE  SYSTEM 

Perhaps  the  simplest  data  transfer  service  provides  for  transmission  of  one  message  at  a  time  from 
a  fixed  sender  to  a  fixed  receiver.  The  sender  must  wait  until  the  previous  message  is  received  before 
sending  the  next  one.  There  is  no  possibility  of  message  loss,  duplication,  or  corruption.  The  system 
is  shown  graphically  in  Figure  1-1.  The  next  section  provides  an  informal  English  description  of  the 
state  transition  machine.  We  will  show  how  it  can  be  represented  in  Affirm  in  the  following  sections. 


3.1.  State  Variables 

There  are  only  a  few  state  variables,  each  performing  a  simple  function.  (Each  state  variable  has 
an  associated  data  type,  as  shown.) 

State:  ControlState 

The  current  status  of  the  service.  This  state  variable  simply  cycles  through  the  four  values  of 
the  enumerated  type  ControlState.  The  four  values  of  the  type  are  ReadyToSend,  Sending, 
ReadyToReceive,  and  Acking  (Acknowledging).  The  state  variable  State  is  tested  by  most  state 
transition  functions  as  a  general  applicability  test:  the  transition  function  will  not  change  the 
state  unless  this  variable  has  the  appropriate  value. 

Sent:  QueueOfMessage 

The  queue  of  messages  that  have  been  sent  to  the  receiver.  One  of  the  properties  to  prove 
about  this  service  is  that  the  queue  of  messages  sent  equals  the  queue  of  messages  received 
(except  for  possibly  the  very  last  message  of  the  Sent  queue,  which  may  not  have  been 
received  yet). 

Received :  QueueOfMessage 

The  queue  of  messages  thau  have  been  received  by  the  receiver. 

Buffer:  QueueOfMessage 

The  queue  of  messages  that  have  been  sent  by  the  sender  but  not  yet  received  by  the  receiver. 
This  state  variable  represents  the  channel  of  a  real  protocol.  In  the  current  protocol,  this  queue 
is  either  empty,  or  has  exactly  one  message  in  it,  the  one  just  sent  (but  of  course  we  have  to 
prove  it,  not  just  say  itl). 

The  types  of  the  state  variables  are  assumed  to  be  explicitly  defined  (e.g.,  type  ControlState ),  or  are 
assumed  to  have  a  standard  definition  (as  is  the  case  with  type  QueueOfMessage). 


3.2.  State  Transitions 

A  few  of  the  state  transition  functions  would  be  requested  by  a  user,  while  others  would  appear  to 
the  user  to  occur  spontaneously.  For  example,  the  user  would  explicitly  request  the  UserSend 
operation,  but  the  SendComplete  operation,  corresponding  to  the  event  "message  pops  out  of  the 
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channel  at  the  receiver’s  end,”  would  appear  to  be  spontaneous  to  the  user.  These  spontaneous 
transitions  are  included  to  explicitly  model  the  delay  involved  in  sending  a  message.  We  consider  this 
to  be  an  important  aspect  of  the  service. 

InitializeService 

Initializes  the  state  variables.  Sent,  Received,  and  Buffer  are  all  initialized  to  the  empty  queue, 
and  State  is  initialized  to  ReadyToSend. 

UserSend(  message) 

Only  applicable  if  State  is  ReadyToSend ;  otherwise,  this  operation  is  a  no-op.  Adds  message  to 
the  Sent  queue,  adds  message  to  Buffer,  and  sets  State  to  Sending. 

SendComplete 

A  spontaneous  event  (the  user  cannot  directly  request  it).  Applicable  only  if  State  is  Sending, 
i.e.,  there  is  an  outstanding  Send  operation  to  be  completed.  Sets  State  to  ReadyToReceive. 

UserReceive 

Applicable  only  if  State  is  ReadyToReceive.  The  message  at  the  front  of  the  Buffer  queue  is 
added  to  Received,  indicating  passage  of  the  message  to  the  user.  State  is  then  updated  to 
Acking- an  abstraction  of  the  process  of  sending  an  acknowledgment  to  the  sender,  telling  of 
the  receipt  of  the  message. 

ReceiveComplete 

A  spontaneous  event,  corresponding  to  the  event  "sender  receives  acknowledgment  of 
message  receipt."  Applicable  only  if  State  is  Acking.  A  message  is  removed  from  Buffer,  and 
State  is  updated  to  ReadyToSend,  indicating  the  cycle  is  complete. 


3.3.  Behavior  of  the  Simple  Message  System 

The  state  machine  starts  by  performing  the  InitializeService  command.  The  system  then  repeatedly 
cycles  through  the  four  states  ReadyToSend,  Sending,  ReadyToReceive,  and  Acking.  Each  of  these 
four  states  has  only  two  successor  states:  itself  (when  a  command  that  is  not  applicable  is  issued,  in 
which  case  there’s  no  change),  and  the  next  in  the  cycle.  (Of  course,  at  any  time  the  InitializeService 
command  can  be  re-issued,  in  which  case  the  machine  is  reset  to  its  initial  state.) 

As  the  system  cycles  through  the  four  states,  it  maintains  an  invariant:  the  sequence  of  messages 
sent  equals  the  concatenation  of  the  sequence  of  messages  received  and  the  single  message 
currently  being  sent  (if  there  is  one).2  This  and  similar  properties  are  called  service  requirements.  If 
the  state  transition  machine  is  specified  correctly,  these  properties  are  straightforward  to  verify. 


2  Almost.  We  will  dtocun  the  correct  formulation  of  this  property  later. 
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3.4.  Converting  State  Transition  Specifications  to  Affirm 
The  Affirm  representation  of  a  state  transition  machine  is  basically  just  a  representation  of  the 
state  vector  of  the  state  machine.  Each  state  variable  forming  one  part  of  the  machine’s  state  vector 
becomes  a  selector  function.  Each  state  transition  function  (command)  becomes  a  constructor. 
There  are  usually  no  extender  functions  in  this  scheme.  The  axioms  simply  state  how  each  state 
variable  is  modified  by  each  state  transition  function. 

3.4.1.  State  Transition  Function  -*•  Constructor 

Each  state  transition  function  (command)  of  the  state  transition  machine  becomes  a  constructor  of 
an  Affirm  type. 

state  machine  SimpleMessageSystem, 

declare s:  SimpleMessageSystem; 
declare  m:  Message; 

constructors 

InitializeService,  UserSend(s,  m),  SendComplete(s),  UserReceive(s),  ReceiveComplete(s):  SimpleMessageSystem; 

Each  constructor  has  as  its  range  the  type  being  defined.  And  each  of  the  constructors  (except  the 
initialization  function)  is  given  a  parameter  of  the  type  being  defined.  This  parameter  represents  the 
entire  state  of  the  system.  Thus  state  or  event  histories  can  easily  be  represented  as  compositions  of 
the  constructor  functions.  For  example,  the  sequence  of  commands  representing  a  machine  cycle 
InitializeService;  UserSend(m);  SendComplete;  UserReceive;  ReceiveComplete 
would  simply  be 

ReceiveComplete(UserReceive(SendComplete(UserSend(lnitializeService,  m)))) 

3.4.2.  State  Variable  -*  Selector 

Each  state  variable  of  the  state  transition  machine  becomes  a  selector  function  in  the  Affirm 
specification.  In  the  Affirm  specification,  each  function  will  take  a  parameter  of  the  type  being 

defined.  Thus  each  state  variable  is  simply  an  extraction  function  of  the  state  vector. 

••lector  States).  ControlState, 

••lectors 

Buffer(a),  Sent(s).  Received(s):  QueueOfMessage; 


3.4.3.  Transition  Definition  -*•  Set  of  Axioms 
The  preceding  subsections  paved  the  way  by  defining  the  domain  and  range  information  of  the 
constructors  and  selectors.  Now  we  must  define  their  semantics.  It  will  become  quite  clear  why  each 
function  carries  along  the  "state"  parameter:  it  provides  a  natural  way  of  describing  a  transition.  We 
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will  demonstrate  the  method  by  writing  the  axioms  for  the  state  variable  Sent.  From  Section  3.2,  we 
know  that  the  state  variable  Sent  is  modified  by  the  initialiieService  operation,  possibly  modified  by 
the  UserSend  operation,  and  not  modified  by  the  remaining  operations  SendComplete,  UserReceive, 

and  ReceiveComplete. 
axioms 

1.  Sent(UserSend(state,  message)) 
mm  H State<state)  «  ReadyToSend 

then  Sent(  state)  Add  m 
else  Sent(atate). 

2.  Sent(SendComplete(state))  »  >  Sent(state), 

3.  Sent(UsefReceive{  state))  «  «  Sen t( state). 

4.  Sent(ReceiveComplete< state))  «  »  SenKstate). 

5.  Sent(lnitialiieService)  «  m  NewQueueQN lesasge; 

Axioms  2, 3,  and  4  simply  state  that  the  operations  have  no  effect  on  the  state  variable.  For  example, 
axiom  2  says  "the  value  of  the  state  variable  Sent  after  a  state  transition  from  state  state  to  state 
SendComplete(state)  is  equal  to  the  value  of  Sent  in  state  state."  Similarly,  axiom  1  says  "if  the  state 
variable  State  in  state  state  is  ReadyToSend,  then  the  operation  UserSend  will  have  an  effect  on  the 
state  variable  Sent;  otherwise  it  won’t."  This  method  of  constructing  a  specification  ensures  that  the 
specification  will  be  complete- the  effects  of  each  command  on  each  state  variable  are  detailed. 


3.5.  The  Affirm  Representation 

The  following  is  a  stylized  representation  of  Affirm  input,  for  the  sake  of  readability.  State 
transition  functions  that  leave  a  state  variable  unchanged  are  not  explicitly  specified;  the  convention 
is  "not  specified,  not  modified."  The  actual  Affirm  input  is  displayed  in  Appendix  I. 

•tat*  machine  SimpleMessageSystem-, 

declare  a:  SimpleMessageSystem; 
declare  m:  Message; 

constructors  InitializeService,  UserSend(s,  m),  SendComptetefs),  UserReceivefe),  ReceiveComplete(s); 
selectors  Bufter(s).  Sent(s),  Received(s):  QueueOfMessage; 
selector  State(s):  ControlState; 

axioms  { 'fnlttalliaSarvtee J 

State(lnitializeService)  «  «  ReadyToSend, 

Buffer(lnitializeServlce)  «  »  NewQi/eoeOt Message, 

SenKlnitiaHzeService)  «  «  NewQueueOfMessage, 

Received(lnitializeService)  «  a  NewOueueOfMessage; 
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axiom*  {U**rS*nd} 

State(UaerSend(s,  m))  »  «  if  State(a)  *  ReadyToSend 
than  Sending 
else  State(s), 

Buffer(UaerSend(s,  m))  ■  *  if  State(s)  =  ReadyToSend 
then  Buffer(s)  Add  m 
else  Buffers), 

Sent(UserSend(s,  m))  *  »  if  State(s)  «  ReadyToSend 
then  Sent(s)  Add  m 
else  Sent(s); 

axioms  {SandComplata} 

State(SendComplete<s))  ■  *  if  States)  =  Sending 

then  ReadyToReceive 
else  State(s); 

axioms  {UsarRacaiva} 

State<UserReceive(s))  *  =  ifState(s)  *  ReadyToReceive 
then  Acking 
else  State(s), 

Received(UserReceive<s))  =  =  if  State(s)  =  ReadyToReceive 

then  Received(s)  Add  Front(Buffer(s)) 
else  Received(s); 

axioms  {RacaivaComplata} 

State(ReceiveComplete(s))  s  *  if  State(s)  =  Acking 

then  ReadyToSend 
else  State(s), 

Buffer(ReceiveComplete<s))  =  =  if  State(s)  =  Acking 

then  Remove(Buffer(s)) 
else  Buffers); 

end  {SimpleMessageSyslem} ; 


3.6.  Properties  of  a  Specification 

To  increase  our  confidence  that  the  state  transition  machine  we  have  specified  is  a  reasonable 
one,  we  can  formulate  certain  properties  we  expect  to  hold  during  the  machine’s  operation.  These 
service  requirements  may  be  proved  using  structural  induction  as  described  in  Section  1.2.2.  We 
present  an  example  of  such  service  requirements  for  the  simple  data  transfer  service. 

A  useful  safety  property  for  this  service  might  be: 

Sent  »  Received  join  Transit 

stating  that  the  messages  received  are  equal  to  the  messages  sent  except  for  any  still  in  transit.  We 
must  be  careful  in  our  definition  of  Transit  to  take  into  account  the  state  Acking  when  the  message  is 
still  in  Buffer,  but  has  been  received.  The  exact  theorem  in  Affirm  would  be: 

theorem  DataTransfarSarvica .  all  s  (Sent(a)  *  Received(s)  joinTransitsfs)); 

def  in#  Trans  it  (s)  *  u  it  State(s)  «  Acking 

than  NewQueueOf  Message 
else  Buffer  (a); 

This  theorem  has  been  proved  in  Affirm. 
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Another  form  of  the  service  requirement  might  be 

( State(s )  «  ReadyToSend)  D  ( Sent(s )  ■  Received(s)) 
stating  that  input  exactly  equals  output  whenever  the  system  returns  to  its  "idle'*  state.  This  turns  out 
to  be  a  special  case  of  the  more  general  theorem  above. 


Liveness  properties  for  this  simple  machine  are  relatively  trivial.  It  is  fairly  obvious  that  the  allowed 
progression  of  states  involves  a  single  fixed  cycle  (ignoring  rejected  operations  having  no  effects), 
where  a  single  message  is  transferred  during  each  cycle.  First,  the  meaning  of  "ignore  rejected 
operations"  is  formalized,  as  follows: 

interface  StripNoOps(s):  SimpleMessageSystem; 

axiom* 

StripNoOps(lnitiatizeService)  =  =  InitializeService, 

StripNoOps(UserSend(s,  m))  =  *  if  Statefs)  *  ReadyToSend 

then  UserSend(StripNoOps(s),  m) 
else  StripNoOps(s). 

StripNoOps(SendComplete(s))  =  =  if  Statefs)  =  Sending 

then  SendComptete(StripNoOps(s)) 
else  StripNoOps(s). 

StripNoOps(UserReceive(s))  =  =  if  State(s)  =  ReadyToReceive 

then  UaerReceive(StripNoOps(s)) 
else  StripNoOps(s). 

StripNoOps(ReceiveComplete(s))  *  *  if  Statefs)  =  Acting 

then  ReceiveComplete(StripNoOps(s)) 
else  StripNoOps(s), 

theorem  StatasMalch,  all  a  (  State(s)  «  State(StripNoOps(s)) 
and  Sent(s)  *  Sent(StripNoOps(s)) 
and  Received(s)  ■  Received(StripNoOps(s)) 
and  Buffer(s)  =  Buffer(StripNoOpa(s))); 

The  definition  of  StripNoOps  simply  formalizes  our  intuition  about  events  having  no  effect  because 
they  occur  at  an  inappropriate  time.  For  example,  a  SendComplete  event  after  a  UserReceive  event 
can  have  no  effect.  The  theorem  StatesMatch  says  that  the  effects  of  a  sequence  of  events  are  the 
same  as  the  effects  of  a  new  sequence  that  has  had  the  no-effect  operations  filtered  out.  This 
theorem  was  proved  in  Affirm. 


In  the  context  of  the  above  definitions,  then,  the  following  theorem  says  that  the  four  operations,  in 
the  right  order,  add  a  message  (and  the  correct  one)  to  those  received,  no  matter  how  many 
additional  "rejected”  operations  may  have  been  interleaved. 

theorem  SarvIcaPrograta,  all  *1,  *2,  m 

(  StripNoOps(s2)  «  RecelveComplete(UserReceive(SendComplete(UserSend(StripNoOpa(s1),  m)») 
andStatefal)  *  ReadyToSend 
imp  State<*2)  >  ReadyToSend 
and  Sent(a2)  «  Sentfal)  Add  m 
and  Recelved(a2)  -  Received(al)  Add  m); 

This  theorem  has  also  been  proved  using  Affirm. 
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Finally  we  note  th*t  the  system  will  progress  around  this  cycle  as  long  as  each  operation  completes 
in  finite  time.  This  is  an  assumption  at  the  service  level,  but  of  course  it  must  be  proved  when  we  see 
how  the  protocol  implements  each  operation. 


3.7.  Alternative  Notations 

Instead  of  implicitly  representing  the  machine's  state  vector,  we  could  have  represented  it  explicitly 
by  defining  qq£  constructor,  say  Const .  Const  takes  a  number  of  parameters  (one  per  individual  state 
variable),  and  creates  one  state  vector  out  of  them: 

constructor  Consf(state,  sent,  received,  buffer):  SimpleMessageSystem; 

The  individual  state  variables  are  then  defined  as  vector-extractors: 

State!  Co  r>sf(state,  sent,  received,  buffer))  =  *  state, 

Sent(Consf(state,  sent,  received,  buffer))  =  =  sent, 

Received ( Const (st ate ,  sent,  received,  buffer))  =  =  received, 

Buffer(Con$r(state,  sent,  received,  buffer))  =  =  buffer; 

and  the  state  transition  functions,  nominally  constructors,  would  become  extenders: 

UserSend(Consf(state.  sent,  received,  buffer),  message) 

*  =  if  state  =  ReadyToSend 

then  Consf(Sending,  sent  Add  message,  received,  buffer  Add  message) 
else  (no  change}  Const( state,  sent,  received,  buffer), 

SendComplete(  Const  (state ,  sent,  received,  buffer)) 

=  *  if  state  =  Sending 

then  Consf(ReadyToReceive,  sent,  received,  buffer) 
else  {no  change}  Corts/f state,  sent,  received,  buffer), 

UserReceive(Consf(state,  sent,  received,  buffer)) 

=  *  if  state  =  ReadyToReceive 

then  Const(Acking.  sent,  received  Add  Front(buffer),  buffer) 
else  {no  change}  Consf(state.  sent,  received,  buffer), 

ReceiveComplete(Consf(state.  sent,  received,  buffer)) 

=  =  if  state  =  Aching 

then  Consf(ReadyToSend.  sent,  received,  Remove(buffer)) 
else  {no  change}  Cortsf( state,  sent,  received,  buffer), 

InitializeService  =  =  Consf{ReadyToSend,  NewQueueOfMessage,  NewQueueOfMessege,  NewQueueOfMessage); 


This  notation  often  results  in  fewer  axioms  overall,  but  each  axiom  is  usually  much  more  complex 
than  those  of  the  notation  we  described  above.  This  is  especially  true  when  one  state  has  a  large  set 
of  successor  states.  We  have  chosen  the  first  notational  method  for  expressing  state  vectors  in 
Affirm  because  of  its  convenience.  The  axioms,  with  a  bit  of  practice,  are  generally  more 
understandable  because  each  is  relatively  simple. 


i 
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4.  VERIFICATION  ISSUES 

As  mentioned  in  Chapter  1,  we  would  ideally  like  to  verify  three  kinds  of  properties  of  a 
specification:  safety  (only  correct  things  happen),  liveness  (eventually  something  happens),  and 
performance  (things  happen  promptly). 

Safety  properties  are  typically  proved  by  structural  induction,  as  was  described  in  Section  1.2.2. 
Most  of  our  work  has  focused  on  this  concern. 

Liveness  properties  may  be  handled  by  showing  that  the  system  terminates: 

1.  Some  operation  is  always  enabled,  or  the  system  has  reached  one  of  its  final  states;  and 

2.  Each  operation  decreases  some  bounded  measure  function,  which  at  some  point  (nominally, 
when  it  evaluates  to  zero)  disables  all  operations  (for  example,  by  setting  a  special  state 
variable  to  false;  presumably  all  the  operations  are  applicable  only  if  the  variable  is  true). 

This  issue  is  discussed  at  length  in  [2].  Temporal  logic  also  provides  convenient  techniques  for 
stating  and  proving  liveness  properties  [20, 33].  We  deal  only  briefly  with  liveness  properties  in  this 
report. 

Performance  properties  have  traditionally  been  dealt  with  by  other  methods  (e.g.,  queueing  theory); 
we  have  not  addressed  this  issue. 

4.1 .  Verifying  Properties  of  a  Specification 

As  noted  in  Section  1 .2,  one  of  the  main  capabilities  of  Affirm  is  the  ability  to  verify  that  a  data  type 
has  certain  desired  properties.  These  properties  are  specified  as  theorems  and  are  then  proved  using 
the  interactive  theorem  prover  of  Affirm. 

Typically  these  theorems  are  invariants  in  the  state  transition  model.  That  is,  they  are  predicates  on 
the  state  that  are  true  in  the  initial  state,  and  are  preserved  across  all  state  transitions.  In  Affirm, 
these  theorems  are  proved  from  the  axioms  of  the  type  being  specified  (and  other  predefined  types) 
by  structural  induction.  In  the  context  of  the  simple  message  system  of  the  preceding  chapter,  to 
prove  a  theorem  P(s)  for  all  states  s,  first  prove  the  theorem  P(lnitializeService)-,  then,  assuming  P(s) 
for  some  state  s,  prove  P{fcn(s))  for  each  constructor  fen  in  the  type.  This  suffices  to  show  P(s)  for  all 
s. 


It  is  also  overkill.  What  is  proved  is  that  any  order  of  occurrence  of  the  events  of  the  state  transition 
machine  is  acceptable;  the  invariant  still  holds.  Carrying  out  such  a  proof  requires  a  ruggedized 
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machine  that  has  extra  tests  to  ensure  that  operations  invoked  at  inappropriate  times  can  do  no  harm: 
no  state  change  occurs.  Real  protocols  have  (implicit)  assumptions  stating  which  operations  can 
happen  when.  It  is  unlikely,  for  example,  that  a  time-out  can  occur  if  there  are  no  messages  that  have 
been  sent  but  not  yet  acknowledged.  Thus  proving  properties  of  a  program  that  uses  an  abstract 
machine  in  a  certain  way  may  be  easier  (and  allow  a  simpler  machine  specification)  than  proving 
properties  of  the  machine  for  arbitrary  programs. 

4.2.  Verifying  the  Protocol  against  the  Service  Specification 

We  must  show  that  the  detailed  system  (composed  of  stations  interacting  according  to  the 
protocol)  does  the  same  thing  as  the  abstract  system  (specified  by  the  service:  see  Section  1.3). 

This  brings  us  to  the  problem  of  what  it  means  for  one  abstract  machine  (or  set  of  machines)  to 
implement  another.  There  are  two  aspects  of  this  relationship: 

1 .  a  static  correspondence  between  each  state  of  the  higher  level  and  the  state(s)  implementing  it 
at  the  lower  level,  showing  that  every  higher  level  state  is  in  fact  implemented;  and 

2.  a  dynamic  correspondence  between  the  transitions  of  the  two  levels,  showing  that  the 
sequence  of  states  reachable  in  the  two  levels  are  the  same. 

Point  1  is  typically  handled  by  giving  a  representation  function  rep  from  the  state  variables  of  the 
lower  level  to  the  state  variables  of  the  higher  level.  The  function  is  specifically  defined  in  this 
direction  because  there  may  be  several  lower  level  states  that  all  represent  the  same  higher  level  state 
(so  the  function  has  no  inverse).  Also,  some  lower  level  states  may  be  intermediate  states  that  do  not 
represent  any  higher  level  state.  As  noted  above,  it  must  be  shown  that  there  is  some  lower  level  state 
to  represent  every  higher  level  state. 

To  address  point  2,  the  conventional  approach  involves  specifying  a  fixed  sequence  of  lower  level 
operations  implementing  each  higher  level  operation.  Then  it  must  be  proved  that  if  the  two  systems 
start  in  corresponding  states,  they  will  end  up  in  corresponding  states  after  corresponding 
operations. 

Let  5  and  s  be  higher  and  lower  level  states  respectively.  Let  OP  be  a  higher  level  operation  and  op 
be  its  lower  level  implementation,  and  let  rep  be  a  representation  function  (from  s  to  $).  Then  this 
method  attempts  to  show  that  for  vach  OP 

V  S,  s  (S  ■  rep(s)  D  OP(S)  -  rep(op(s))) 


The  difficulty  of  this  approach  in  the  protocol  domain  is  that  a  higher  level  operation  such  as 
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sending  a  message  may  be  accomplished  by  a  nondeterministic  sequence  of  lower  level  operations, 
including  transmission,  loss,  time-outs,  retransmissions,  and  receptions.  Typically  there  will  be  a 
single  low-level  operation  that  starts  the  accomplishment  of  the  higher  level  operation  by  "posting” 
some  work  to  be  done.  This  will  then  be  followed  by  a  nondeterministic  series  of  tower  level 
operations,  invisible  at  the  top  level,  that  complete  the  results  of  the  higher  level  operation  in  the 
unreliable  low-level  environment.  These  latter  effects  may  be  viewed  as  one  or  more  spontaneous 
transitions  of  the  higher  level  machine.  Section  5  gives  an  example  of  this  sort. 

In  this  type  of  lower  level  specification,  there  are  two  sorts  of  operations:  one  set  invoked  directly 
by  the  users  of  the  system  (corresponding  to  the  higher  level  operations),  and  a  second  set  of  internal 
operations. 


Verification  of  this  type  of  lower  level  specification  is  similar  to  the  conventional  situation  discussed 
above,  but  must  be  augmented  by  a  proof  that  the  spontaneous  higher  level  transitions  (and  only 
such  transitions)  are  accomplished  by  the  internal  operations  of  the  lower  level.  This  additional  proof 
is  facilitated  by  defining  the  internal  operations  in  a  ruggedized  fashion  that  includes  tests  in  their 
definitions  to  force  them  to  produce  no  changes  if  invoked  at  inappropriate  times.  The  additional 
theorems  to  be  proved  take  the  following  form:  From  any  low-level  state  corresponding  to  a  higher 
level  state  with  spontaneous  transitions,  the  next  lower  level  state  that  "maps  up"  and  can  be  reached 
by  any  sequence  of  internal  lower  level  operations  must  correspond  to  the  correct  higher  level  state. 
We  can  define  this  recursively  as  follows. 

V  S  such  that  S  has  one  or  more  spontaneous  transitions 
(V  s  such  that  S  =  rep(s) 

(SpontSucc(S)  =  rep(UpSuccessors(s,  S)))) 

where  rep  is  extended  in  the  natural  manner  to  sets 

SpontSucc(S)  is  the  set  of  states  reached  from  S  by  spontaneous  transitions 
UpSuccessors(s,  S)  = 

(s2:  Successors,  s2)  and  MapsUp(s2)  and  S  *■  rep(s2)) 

U  UpSuccessors(s3,  S) 

Vs3:  Successors,  s3)  and  -MapsUp(s3) 

Successors),  s2)  a  3  mferna/Op  such  that  (s2  *  internalOp(sl )) 

MapsUp(s)  »  true  if  s  represents  some  high-level  state 

This  general  formulation  often  simplifies  considerably,  as  shown  in  the  example  in  Chapter  5. 
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4.3.  Verifying  a  Program  against  the  Protocol  Specification 

If  we  followed  the  pattern  of  the  lower  level  (protocol)  and  higher  level  (service)  specifications 
discussed  above,  each  operation  of  the  protocol  specification  would  be  implemented  by  a  separate 
Pascal  procedure.  However,  an  actual  implementation  of  a  protocol  is  somewhat  more  constrained. 

A  state  transition  machine  defines  a  global  state  and  specifies  how  transitions  change  the  state 
variables.  Since  the  purpose  of  protocols  is  to  provide  for  communication  between  disjoint 
processes,  an  actual  implementation  will  be  divided  into  cooperating  stations  (as  described  in  Section 
1 .3);  only  the  state  variables  describing  the  communications  medium  will  be  shared  between  stations. 

Since  losses  are  a  spontaneous  behavior  of  the  medium,  they  are  not  implemented. 

While  it  was  convenient  for  our  specification  to  allow  operations  to  be  invoked  in  any  order,  only 
certain  sequences  of  operations  are  efficient.  (For  example,  it  makes  little  sense  for  the  sender  to 
retransmit  without  first  checking  for  acknowledgments.)  Therefore  the  programs  typically  exhibit  only 
a  subset  of  the  allowable  behavior.  The  intention  is  that  only  inefficient  event  sequences  have  been 
omitted. 

Of  course,  many  properties  of  states  proved  at  higher  levels  may  be  transferred  down  to  programs. 
However,  the  constraints  introduced  by  the  program  may  require  additional  proofs  for  liveness,  e.g., 
the  constraints  do  not  introduce  deadlock. 


5.  DETAILED  EXAMPLE:  THE  ALTERNATING  BIT 
PROTOCOL 

We  will  continue  the  exposition  of  our  methodology,  using  the  Alternating  Bit  protocol  as  an 
example.  First  we  will  specify  a  protocol  providing  the  simple  data  transfer  service  described  earlier. 
We  will  then  perform  the  various  verification  tasks. 

5.1 .  A  Brief  Description  of  the  Protocol 

The  Alternating  Bit  protocol  [1 , 5,  21 ,  20,  6]  is  intended  to  provide  a  simple  but  reliable  message 
transfer  service  over  an  unreliable  transmission  medium.  It  attaches  a  one-bit  sequence  number  to 
each  message  sent,  and  waits  for  an  acknowledgment  of  the  receipt  of  the  message  by  the 
destination.  The  sequence  number  is  complemented  on  each  new  message  sent-hence  the  name  of 
the  protocol.  If  the  acknowledgment  is  not  received  within  a  time-out  period,  the  message  is 
retransmitted  (with  the  sequence  number  unchanged).  The  protocol  guarantees  correctly  sequenced 
delivery  of  messages  even  if  the  medium  loses  messages  and  acknowledgments,  but  the  medium 
cannot  reorder  messages. 

To  accomplish  these  functions,  the  sender  and  receiver  stations  maintain  local  sequence  number 
counters.  The  sender  uses  its  counter  to  remember  the  sequence  number  to  attach  to  the  next 
transmission.  The  receiver  uses  its  counter  to  remember  the  sequence  number  of  the  next  message  it 
expects  to  receive,  thus  allowing  for  the  removal  of  duplicate  messages  (which  will  be  sent  if  an 
acknowledgment  is  lost). 

The  Alternating  Bit  protocol  is  a  simple  instance  of  a  general  class  of  data  transfer  protocols  using 
positive  acknowledgments  and  retransmission  on  errors  [46, 44, 24].  This  simple  example  allows  only 
one  unacknowledged  message  to  be  transmitted  at  a  time.  More  complex  protocols  in  this  class  use 
larger  sequence  numbers  and  allow  multiple  outstanding  messages. 

In  Section  5.2  we  provide  an  informal  definition  of  a  state  transition  machine  for  the  Alternating  Bit 
protocol,  and  in  Section  5.3  this  specification  is  translated  into  an  Affirm  representation.  We  then 
discuss  the  major  verification  step,  showing  that  the  protocol  implements  its  service  correctly.  We  will 
then  discuss  an  important  invariant  of  the  protocol  specification  (independent  of  the  service).  Finally 
we  give  algorithms  for  the  sender  and  receiver  stations,  and  show  that  these  algorithms  property 
implement  the  protocol. 
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5.2.  A  State  Transition  Machine  for  the  Alternating  Bit  Protocol 

The  protocol  machine  described  in  this  section  closely  parallels  the  service  machine  described  in 
Chapter  3,  with  the  addition  of  details  concerning  the  internal  operation  of  the  protocol.  The  protocol 
is  defined  as  a  single  machine  rather  than  as  separate  sender  and  receiver  components  (see  Section 
7.1).  Figure  5-1  illustrates  the  main  data  structures  and  operations  of  the  protocol. 


ProtocolSend 


LoseAck 


Figure  5-1 :  The  protocol  state  transition  machine 


5.2.1 .  Data  Types  Used  in  the  Specification 
The  protocol  uses  a  few  more  data  types  than  the  service  specification  does.  Their  informal 
descriptions  are  gathered  here  for  convenience. 

Message 

As  in  the  service  specification,  this  type  is  a  minimally  defined  data  type  that  represents  abstract 
contents. 

Bit  An  enumerated  type  with  two  elements,  arbitrarily  called  ga  and  oft  Functions  include  a  ’’flip*' 
operation  that  flips  the  value  (from  qq  to  off  or  vice  versa),  represented  by  the  unary  not 
operator 
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Packet 

A  record  (or  tuple)  with  two  components:  a  value  of  type  Bit  (i.e.,  a  sequence  number)  and  a 
value  of  type  Message. 

Medium 

Really  a  OueueOfPacket  with  the  addition  of  operations  to  "lose"  packets.  Further 
enhancements  (e.g.,  to  allow  the  reordering  of  packets)  might  be  desired  in  a  more  realistic 
medium.  The  channels  of  the  protocol  are  of  this  type.  The  Transmit  operation  takes  a  value  of 
type  Medium  and  a  value  of  type  Packet  and  yields  a  value  of  type  Medium.  It  thus  corresponds 
to  the  Add  operation  of  the  Queue  type.  Similarly,  Receive  corresponds  to  the  Queue  operation 
Remove. 

OueueOfPacket,  QueueOf Message,  SequenceOf Message 
Standard  data  types  from  the  Affirm  Type  Library. 


5.2.2.  State  Variables 

SenderToReceiver :  Medium 

The  channel  from  the  sender  to  the  receiver. 

Receiver? oSender:  Medium 

The  channel  from  the  receiver  to  the  sender.  For  convenience,  entire  packets  are  returned  as 
acknowledgments,  rather  than  just  the  sequence  numbers. 

Pending :  OueueOfPacket 

The  packet  currently  being  transmitted,  if  any.  Pending  is  either  empty  (Le., 
NewQueueOlPacket),  or  contains  exactly  one  packet.  A  queue  type  was  used  instead  of  a 
simple  packet  in  order  to  avoid  notions  of  a  null  packet,  and  to  allow  future  extensions. 

SSN:  Bit 

The  sender’s  current  sequence  number  (i.e.,  the  next  acknowledgment  of  interest). 

RSN:  Bit 

The  receiver's  current  sequence  number  (i.e.,  the  number  of  the  next  packet  expected). 
ReceiverBuffer:  OueueOfPacket 

The  packet  received  but  not  yet  delivered  to  the  user  (if  any).  ReceiverBuffer  is  either  empty,  or 
has  exactly  one  element.  A  queue  type  was  used  for  convenience. 

Sent:  SequenceOfMessage 

A  sequence  of  all  the  messages  sent  but  not  necessarily  acknowledged  yet.  (This  variable 
would  not  be  present  in  a  real  implementation;  it  is  for  specification  purposes.) 

Received:  SequenceOfMessage 

A  sequence  of  all  the  messages  successfully  received.  (This  variable  would  not  be  present  in  a 
real  implementation;  it  is  for  specification  purposes.) 
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Of  course,  not  all  these  data  structures  are  visible  or  available  to  both  stations  (sender  and 
receiver). 


5.2.3.  State  Transition  Functions 

InitializeProtocol 

Set  the  counters  and  the  queues  to  their  initial  values. 

ProtocolSend[m ) 

Given  a  message  jn,  try  to  send  the  message  as  a  packet.  If  no  message  is  waiting  to  be 
acknowledged  ( Pending  =  NewQueueOf Packet)  then  accept  the  message  m  (by  appending  it 
to  Sent)  and  transmit  it  (by  constructing  a  packet  with  the  current  SSN  and  adding  the  packet  to 
SenderToReceiver).  Also  remember  that  the  packet  is  waiting  to  be  acknowledged  (by  putting  it 
in  Pending ). 

ReceivePacket 

Receive  a  packet,  if  one  is  available.  If  SenderToReceiver  is  nonempty,  remove  and  examine 
the  first  packet.  If  it  is  the  one  expected  (its  sequence  number  matches  RSN ),  then  place  it  in 
ReceiverBuffer  and  flip  RSN.  If  the  packet  has  already  been  delivered,  then  send  an 
acknowledgment  by  copying  the  packet  to  ReceiverToSender. 

Deliver 

Deliver  a  new  message  (if  there  is  one  to  be  delivered)  to  the  user.  If  a  message  is  available  in 
ReceiverBuffer,  append  it  to  the  Received  queue,  and  acknowledge  the  message  (by  copying  it 
to  ReceiverToSender).  Clear  ReceiverBuffer. 

ReceiveAck 

Receive  an  acknowledgment,  if  any  exists  to  be  received.  If  ReceiverToSender  is  not  empty, 
then  remove  the  first  packet.  If  the  packet’s  sequence  number  doesn’t  match  SS/v,  then  ignore 
the  packet.  Otherwise,  flip  SSN  and  empty  Pending  (preparing  for  another  Send  operation). 

Retransmit 

Add  the  message  in  Pending,  if  any,  to  SenderToReceiver,  i.e.,  re-send  it. 

LosePacket 

Lose  a  packet  by  removing  the  front  packet  from  SenderToReceiver,  if  it  is  not  empty. 

LoseAck 

Lose  an  acknowledgment  by  removing  the  front  of  ReceiverToSender,  if  it  is  not  empty. 

As  an  example,  a  typical  state  of  the  system  might  be 

ReceiveAck(Deliver(ReceivePacket(ProtocolSend(lnitializeProtocol,  m)))) 

This  represents  the  sequence  of  operations  (reversed  from  their  functional  representation) 
InitializeProtocol;  ProtocolSend(m);  ReceivePacket;  Deliver;  ReceiveAck 
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5.3.  The  Affirm  Representation 

As  was  the  case  with  the  service  specification,  we  simply  turn  state  variables  into  selector  functions 
of  a  data  type;  state  transition  functions  (commands)  become  constructors.  The  definitions  of  the 
state  transition  functions  become  axioms.  All  the  functions  in  the  Affirm  representation  carry  along 
an  explicit  parameter  of  the  type  being  defined;  it  is  a  characterization  of  the  current  state. 


What  is  displayed  here  is  a  stylized  version  of  the  axioms,  omitting  all  axioms  stating  that  some 
selector  is  not  modified  by  some  constructor.  Appendix  II  contains  the  actual  Affirm  input, 
state  machine  ABProtocol; 

declare  s.  ABProtocol; 
declare  m:  Message; 

constructors 

InitializeProtocol,  ProtocolSend(s,m),  ReceivePacket(s),  Deliver(s),  ReceiveAck(s),  Retransmits),  loseAck(s).  LosePackets); 
selectors  InitialSequenceNumber,  RSN(s),  SSN(s):  Bit; 
selectors  ReceiverT oSender(s) ,  SenderToReceiver(s):  Medium; 
selectors  Received(s),  Sent(s):  QueueOfMessage; 
selectors  Pending(s),  ReceiverBuffer(s):  OueueOfPacket; 

axioms  { InitializeProtocol: } 

Pendingf  InitializeProtocol)  =  *  NewOueueOfPacket, 

Received(lnitializeProtocol)  =  =  NewQueueOf  Message, 

ReceiverBuffer(lnitializeProtocol)  =  =  NewOueueOfPacket, 

ReceiverToSender(lnitializeProtocol)  =  =  InitializeMedium, 

RSN(lnitializeProtocol)  a  *  InitialSequenceNumber, 

SenderToReceiver(lnitializeProtocol)  a  =  InitializeMedium, 

Sent(lnitializeProtocol)  =  =  NewQueueOfMessage, 

SSN(lnitializeProtocot)  a  a  InitialSequenceNumber; 

axioms  {Profoco/Send:} 

Pending(ProtocoiSend(s,  m))  =  =  if  Pending(s)  a  NewOueueOfPacket 

then  NewOueueOfPacket  Add  MakePacket(m,  SSN(s)) 
else  Pending(s), 

SenderToReceiver(ProtocolSend(s,  m))  =  =  if  Pending(s)  a  NewOueueOfPacket 

then  Transmit(SenderToReceiver(s),  MakePacket(m,  SSN(s))) 
else  SenderToReceiver(s), 

Sent(ProtocolSen<j(s,  m))  a  art  Pending(s)  >  NewOueueOfPacket 

then  Sent(s)  Add  m 
else  Sent(8); 

axioms  {Paca/vePackef:} 

Receiver  Buff er(ReceivePacket(s))  =  =  H  Seq(Front{SenderToReceiver(s)))  a  RSN(s) 

and  SenderToRecelveta)  -  a  InitializeMedium 
then  NewOueueOfPacket  Add  FrontfSenderToReceiverfs)) 
else  ReceiverBuffer(a), 

ReceiverToSender(ReceivePacket(s))  a  a  if  SenderT oRecetver(s)  -  a  InitializeMedium 

and  ReceiverBuffets)  a  NewOueueOfPacket 
and  RSN(s)  ~  a  Seq(Front(SenderT.oReceiver(a))) 
then  Transmlt(RecetverToSender(s),  Front(SenderToReceivar(s))) 
else  ReceiverT oSender(a) , 

RSN(ReceivePacket(s))  a  a  if  Seq(Front(SenderToReceiver(s)))  a  RSN(s)  and  SenderT oRece*ver(s)  -  a  InitializeMedium 
then  -RSN(a) 
else  RSN(s), 

SenderToReceiver(ReceivePacket(a))  a  >  Receive<SenderToRecefver(s)); 
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axioms  {Oatfvar:} 

Rec«ived(Deliver(s))  *  «  rt  ReceiverButter(s)  «  NewOueueOfPacket 
than  Received(s) 

else  Received(s)  Add  Text(Front(ReceiverBuffer(8))). 

ReceiverBufferfDeliverfs))  *  =  NewOueueOfPacket, 

Received oSender(Deliver(s))  =  =  if  ReceiverBuffer(s)  ■  NewOueueOfPacket 

then  ReceiverToSender(s) 

else  Transmit(ReceiverToSender(s),  Front(Receiver8uffer(s))); 

axioms  {RecelveAck) 

Pending(ReceiveAck(s))  =  *  if  Seq(Front(ReceiverToSender(s)))  =  SSN(s)  and  ReceiverToSender<s)  -  «  InftfalizeMedium 
then  NewOueueOfPacket 
else  Pending!*), 

ReceiverToSender(ReceiveAck(s))  =  =  Receive(ReceiverToSender(s)), 

SSN(ReceiveAck(s))  *  =  H  Seq(Front(ReceiverToSender(s)))  ■  SSN(s)  and  ReceiverToSender(s)  -  «  InftiattzeMedium 
then  -SSN(s) 
else  SSN(s); 

axiom  {Retransmit) 

SenderToReceiver(Retransmit(s))  =  =  if  Pending(s)  «  NewOueueOfPacket 

then  SenderToReceiver(s) 

else  Transmit(SenderToReceiver(s),  Front(Pending(s»); 

axiom  {LoseAck:} 

Receiver T oSender(Loee Ack(s))  «  *  Receive(ReceiverToSender(s)); 
axiom  {LosePacket:} 

SenderToReceiver(LoaePacket(s))  ■  »  Receive(SenderToReceiver(s)); 
end  {ABProlocol) ; 


5.4.  Verifying  the  Protocol  against  the  Service  Specification 

This  section  presents  a  detailed  example  of  how  to  verify  that  a  lower  level  state  transition  machine 
specification  implements  a  higher  level  one.  In  this  case  the  system  in  question  is  the  Alternating  Bit 
protocol,  and  the  two  levels  are  the  service  (higher)  and  protocol  (lower)  specifications. 

5.4.1.  Safety 

The  service  specification  (see  Section  3.5)  includes  UserSend  and  UserReceive  operations,  and  an 
initializeService  operation  to  initialize  the  system,  all  meant  to  be  invoked  by  the  users  of  the  service. 
It  also  includes  spontaneous  transitions  SendComplete  and  ReceiveComplete,  modeling  the 
completion  of  the  UserSend  and  UserReceive  operations  within  the  distributed  system  providing  the 
service.  Hence  there  are  four  control  states  at  the  service  level,  as  shown  in  Figure  1-1,  with  the  two 
intermediate  states  explicitly  displaying  the  delay  between  one  user  initiating  an  operation  and  the 
other  user  becoming  aware  of  it.  The  state  variables  used  at  this  level  include  a  buffer  Buffer  lor 
messages  sent  but  not  yet  received  (at  most  one  is  allowed),  and  queues  Sent  and  Received  that 
maintain  histories  of  all  messages  sent  and  received  (these  are  only  used  for  specification  purposes). 
There  is  also  a  control  state  variable  State  with  four  possible  values. 
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The  protocol  level  (see  Section  5.3)  has  operations  corresponding  to  each  of  the  user  operations  at 
the  service  level: 

InitializeService  -*  InitializeProtocol 
UserSend  -*  ProtocolSend 
User  Receive  -*  Deliver 

There  is  also  a  second  set  of  protocol  operations  that  collectively  accomplish  the  spontaneous 
operations  of  the  service  level.  These  are  ReceivePacket,  ReceiveAck,  LosePacket,  LoseAck,  and 
Retransmit.  The  service-level  state  variables  Sent  and  Received  are  implemented  transparently,  while 
Buffer  is  implemented  as  the  text  of  the  first  packet  in  the  queue  of  packets  called  Pending.  The 
service-level  control  states  (ReadyToSend,  Sending,  ReadyToReceive,  and  Acking)  correspond  to 
four  defined  state  classes  at  the  protocol  level  (S7,  S2,  S3,  and  S4).  Figure  5-2  summarizes  these 
correspondences  informally. 

Service  Protocol 

InitializeService  InitializeProtocol 

Sent  Sent 

Received  Received 

Buffer  Text(Front(Pending)) 

State 

ReadyToSend  Si 

Sending  S2 

ReadyToReceive  S3 

Acking  S4 

UserSend  ProtocolSend 

UserReceive  Deliver 

SendCompiete  i  any  sequence  of  the  operations 

ReceiveComplete  f  { ReceivePacket ,  ReceiveAck,  Retransmit,  LosePacket,  LoseAck } 

Figure  5*2:  The  correspondence  between  service  and  protocol- level  state  variables 

Our  method  of  proving  that  a  protocol  implements  its  service  specification  is  to  convert  each  of  the 
service-level  axioms  into  a  theorem  at  the  protocol  level,  and  then  to  prove  these  theorems  using  the 
protocol  specification.  This  follows  the  method  of  [17].  Appendix  lll.l  shows  the  formal 
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correspondence  between  functions  at  the  two  levels  using  a  representation  function  rep,  and 
Appendix  111.2  defines  the  protocol-level  state  classes.  The  basic  method  is  to  replace  each 
occurrence  of  the  service  machine  state  in  the  axioms  of  the  service  specification  by  the  rep  of  its 
corresponding  protocol  states,  and  then  to  use  the  other  rewrite  rules  displayed  in  Appendix  111.1  until 
the  expression  is  reduced  to  terms  involving  only  protocol-level  selectors  and  constructors. 

This  conversion  is  most  conveniently  discussed  in  three  portions.  The  easiest  axioms  to  convert 
are  those  defining  the  results  of  the  user  operations  ( UserSend ,  UserReceive,  and  InitializeService ) 
on  the  state  variables.  Since  each  service-level  operation  is  directly  implemented  by  a  single 
protocol- level  operation,  and  the  state  variables  also  have  a  simple  correspondence,  the  resulting 
theorems  are  easily  obtained.  Appendix  111.3  shows  how  two  service  axioms  are  converted  in  detail, 
and  Appendix  111.4  gives  all  of  the  resulting  theorems  in  this  category. 

The  next  group  of  theorems  are  those  concerning  the  effects  of  the  spontaneous  service 
operations  on  the  state  variables.  Here  there  is  no  fixed  correspondence  of  one  protocol  operation 
for  each  service  operation.  Instead,  we  wish  to  show  that  aoy  sequence  of  the  five  spontaneous 
protocol  operations  (ReceivePacket,  ReceiveAck ,  LosePacket,  LoseAck,  and  Retransmit)  will  have  the 
specified  effect.  For  state  variables  Sent  and  Received  this  is  simple  because  the  spontaneous 
operations  are  specified  to  have  og  effect  on  these  variables.  The  first  two  theorems  of  Appendix  111.5 
state  that  each  individual  operation  will  have  no  effect,  so  we  can  also  conclude  that  any  sequence  of 
these  operations  will  have  no  effect.  This  may  be  viewed  as  a  special  case  of  structural  induction, 
considering  only  the  spontaneous  operators,  and  attempting  to  show  that  Sent  (or  Received)  is 
invariant. 

The  case  for  Buffer  is  more  complex  since  there  is  a  possible  effect  from  the  spontaneous 
operations.  We  must  show  that  if  the  system  is  not  in  state  54  (corresponding  to  Acking  in  the  service 
specification),  then  there  will  be  no  effect,  and  if  it  is  in  state  S4,  then  Suffer  will  become  empty  (i.e., 
NewQueueOfMessage).  The  first  case  is  similar  to  the  situation  for  Sent  and  Received,  with  the 
additional  constraint  that  the  system  can  never  enter  state  S4  from  another  state  by  spontaneous 
operations.  The  third  theorem  of  Appendix  111.5  shows  that  no  single  action  can  modify  Buffer  in  this 
case,  and  therefore  no  sequence  can,  as  above.  For  the  S4  case,  the  final  theorem  of  Appendix  111.5 
states  that  the  spontaneous  operations  either  leave  the  system  in  state  S4  with  Buffer  unchanged,  or 
set  Buffer  to  NewQueueOfMessage  and  enter  state  SI.  Once  in  state  Si,  we  know  from  the  previous 
theorem  that  there  will  be  no  further  change  to  Buffer.  We  can  then  conclude  that  if  the  protocol 
progresses  (to  state  S 1),  it  behaves  as  specified  in  the  service.  This  proves  the  safety  of  the  protocol. 
A  separate  argument  is  necessary  to  prove  liveness. 
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The  final  set  of  theorems,  in  Appendix  111.6,  covers  the  effects  of  the  operations  on  the  service-level 
state.  For  the  user  operations,  we  must  show  that  the  correct  next  state  is  generated  by  the 
corresponding  protocol  operation  for  each  of  the  four  states  the  system  may  be  in.  This  is  stated  in 
the  first  and  fourth  group  of  theorems  (the  initial  state  was  already  covered).  For  the  spontaneous 
operations,  the  situation  is  similar  to  Buffer  above.  We  must  show  that  any  sequence  of 
ReceivePacket,  ReceiveAck,  LosePacket,  LoseAck ,  and  Retransmit  can  cause  only  the  transitions 
specified  for  SendComplete  or  ReceiveComplete  (i.e.,  if  the  system  progresses  to  a  new  state  at  all,  it 
is  the  correct  one).  For  the  most  part  these  theorems  say  that  no  state  change  takes  place-only 
theorems  Si  Sued,  S2Succ2,  and  S4Succ3  show  actual  progress  (page  51).  Once  again,  only  safety 
is  covered  here. 

All  the  theorems  in  Appendix  III  have  been  proved,  showing  that  the  protocol  correctly  implements 
the  service.  (The  proofs  of  all  theorems  claimed  to  have  been  proved  in  this  report  are  documented  in 
[51].)  The  proofs  require  a  number  of  definition  invocations  and  substitutions  that  are  tedious.  They 
also  require  several  lemmas  concerning  the  relationship  between  SSW  and  the  sequence  numbers  of 
the  packets  in  the  mediums.  We  cite  just  two  as  examples: 

theorem  PktsOldRP,  all  s,  med  (PktsOld(s,  med)  imp  PktsOld(ReceivePacket(s),  med)); 
theorem  PktsOldPS, 

all  s,  m,  med  (  Pending(s)  -  =  NewQueueOfPacket 
and  PktsOld(s,  med) 
imp  PktsOtd(ProtocolSend(s,  m),  med)); 

Theorem  PktsOldRP  says  that  if  the  packets  in  the  medium  med  are  old  (i.e.,  with  sequence  number 
not  equal  to  SSNfs)),  then  they  are  still  old  after  a  ReceivePacket  event-the  event’s  effects  on  the 
medium  are  limited  to  simply  removing  a  packet.  All  the  remaining  packets  are  unaffected. 

5.4.2.  Liveness 

In  order  to  deal  with  liveness  concerns,  we  must  show  that  the  implementation  for  each  service- 
level  operation  terminates.  This  is  trivial  for  the  user  operations,  since  each  is  directly  implemented 
by  a  single  protocol  operation  assumed  to  terminate.  The  difficulty  comes  with  the  so-called 
spontaneous  operations.  We  must  show  that  a  finite  sequence  of  internal  protocol  operations  serves 
to  accomplish  the  desired  effect.  Considering  the  SendComplete  operation  as  an  example,  an 
argument  of  the  following  sort  is  necessary. 

1.  In  (protocol)  state  S2  (corresponding  to  service  state  Sending ),  the  Retransmit  operation  is 
enabled  and  may  place  an  arbitrary  number  of  packets  in  the  SenderToReceiver  medium. 

2.  In  state  S2,  if  one  of  these  packets  reaches  the  receiver,  the  ReceivePacket  operation  will 
achieve  the  desired  effects  of  SendComplete  (i.e.,  change  the  state  to  S3,  corresponding  to 
ReadyToReceive). 
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3.  If  a  large  enough  (but  finite)  number  of  packets  are  transmitted  by  the  sender,  one  will  reach  the 
receiver. 

These  three  points  taken  together  imply  that  a  finite  number  of  protocol  internal  operations  will 
accomplish  the  SendComplete  service  operation.  A  similar  argument  holds  for  the  ReceiveComptete 
operation.  Points  1  and  2  follow  directly  from  the  axioms  for  Retransmit  and  ReceivePacket.  Point  3, 
however,  requires  an  additional  constraint  on  the  simple  medium:  the  number  of  packets  that  may  be 
lost  is  bounded.  As  yet,  there  is  no  convenient  method  for  expressing  such  eventual  delivery 
constraints  in  Affirm.  Our  liveness  arguments  must  therefore  remain  informal.  Berthomieu  [2]  and 
Hailpem  [19, 20]  deal  with  these  concerns. 

5.5.  Protocol  Properties  and  Invariants 

As  stated  in  Section  1.3.2,  the  essential  verification  of  a  protocol  involves  showing  that  it  meets  its 
service  specification.  However,  it  is  also  possible  to  prove  properties  of  the  protocol  specification 
itself,  independently  of  any  service  specification.  In  particular,  a  state  invariant  similar  to  the  service 
requirements  discussed  in  Section  3.6  is  worth  some  discussion.  Proving  the  invariant  gives  added 
confidence  that  the  protocol  specification  is  correct.  The  system  invariant  for  the  Alternating  Bit 
protocol  states  that  the  protocol-level  system  is  always  in  one  of  its  four  valid  state  classes: 

th*or»m  MalnSystamlnvariant ,  all  a  (InSl(s)  or  lnS2(s)  or  InSSW  or  lnS4(a)); 

We  also  note  that  by  the  definition  of  protocol  state  ST  (in  Section  111.2), 

InSl  (s)  D  (Sent(s)  ■  Received(s)) 

This  is  a  protocol-level  version  of  the  service  requirement. 

The  system  invariant  has  been  proved.  The  proof  makes  use  of  the  theorems  of  Appendix  111.6. 
Those  theorems  essentially  detail  how  the  state  changes  for  each  possible  event.  Most  say  that  no 
change  occurs.  As  with  most  abstract  data  types,  much  of  the  difficulty  with  this  proof  lies  in 
developing  a  suitable  invariant.  We  experimented  with  several  versions  of  the  protocol  axioms  and 
state  class  definitions  before  developing  the  present  form. 

5.6.  Implementation 

Having  specified  the  Alternating  Bit  Protocol  and  proven  that  it  has  some  desired  properties,  we 
must  provide  an  implementation  that  meets  these  specifications.  (See  Section  4.3  for  a  general 
discussion.)  Our  implementation  (in  Appendix  IV)  has  two  stations: 

•  Sender  contains  procedures  ProtocolSend,  SenderTimeout,  and  InitSender,  and 

-  Receiver  contains  ReceivePacket,  Deliver,  and  initReceiver. 
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They  share  the  Medium  variables  SenderToReceiver  and  ReceiverToSender.  Since  both  stations 
have  local  variables,  we  need  two  initialization  routines.  All  other  procedures  correspond  to  the 
similarly- named  events  in  the  protocol  specification,  except  for  SenderTimeout.  It  combines  the 
Retransmit  and  ReceiveAck  events.  Like  the  events  of  the  specification,  all  procedures  have  no  effect 
on  the  system  if  they  are  called  at  an  inappropriate  time. 

Program  variables  correspond  to  state  variables  of  the  specification.  Each  procedure  has  an 
assertion  of  the  form 

VariablesMatch(s,  ..vars..)  imp  VariablesMatch(event(s),  ..new  vars..) 

In  other  words,  for  any  state  s  that  corresponds  to  the  initial  values  of  the  program  variables,  the  state 
resulting  from  the  listed  event  will  correspond  to  the  variables  after  the  routine  finishes.  (See  Section 
IV.4.)  For  example,  the  assertion  DPost  (page  55)  says  "given  any  state  s  whose  selectors  Sent, 
ReceiverBuffer,  and  ReceiverToSender  match  the  corresponding  receiver  variables,  the  new  state 
resulting  from  a  Delivers)  event  will  have  selectors  that  correspond  to  the  values  of  the  variables  after 
Deliver  is  executed."  PSPost  (the  assertion  for  ProtocolSend)  adds  one  more  stipulation: 
ProtocolSend  sets  a  bit  to  inform  its  caller  Whether  it  had  any  effect. 

The  partial  correctness  of  all  these  procedures  has  been  proven  using  Affirm.  The  proofs  were 
quite  straightforward,  using  only  one  lemma  about  the  data  type  definitions  and  one  lemma  about  the 
protocol  specification.  Theorem  Pendinglnvariant  states  that  Pending  contains  no  more  than  one 
packet.  It  was  easily  proven  from  the  axioms  without  reference  to  any  other  protocol  invariants. 

theorem  SeqMatch(med,  bit)  imp  (~S6qmatch(med,  -bit))  and  med  -  «  NewQueueOfPacKet; 

theorem  Pendinglnvariant,  Remove(Pending(s))  =  NewQueueOfPacket; 

Since  the  implementation  is  in  keeping  with  the  specification,  its  safety  follows  from  the  earlier 
proof  (in  Section  5.4).  Liveness  has  not  been  formally  proven  for  either  level.  Any  liveness  proof  must 
consider  that  the  implementation  does  not  exercise  the  full  range  of  event  sequences  possible  under 
the  specification.  (For  example,  Retransmit  is  always  preceded  by  ReceiveAck .)  Informally,  It  may  be 
seen  that  only  ineffective  sequences  have  been  excluded,  so  progress  will  not  be  impeded. 


6.  FURTHER  APPLICATIONS 

This  chapter  briefly  mentions  some  further  work  we  have  accomplished  in  applying  our 
methodology  to  several  more  complex  protocols. 

6.1.  Stenning’s  Data  Transfer  Protocol 

The  protocol  described  in  [44]  ignores  the  aspects  involved  in  connection  establishment,  and 
instead  emphasizes  the  data  transfer  aspects.  It  is  designed  to  operate  correctly  even  though  the 
channel  may  lose,  duplicate,  or  re-order  packets  in  transit.  It  is  a  generalization  of  the  Alternating  Bit 
protocol  as  discussed  in  Section  5.1 ,  since  it  allows  several  messages  to  be  in  transit  at  once. 

Stenning  defined  two  processes:  a  transmitter  and  a  receiver.  The  transmitter  sends  messages 
from  a  given  sequence  of  messages  to  the  receiver,  using  a  communication  line.  The  receiver  in  turn 
accepts  messages  from  the  line,  stores  them  in  an  output  sequence,  and  acknowledges  their  receipt 
by  sending  a  message  to  the  transmitter  via  another  communication  line.  The  communication  lines 
are  unreliable;  messages  traveling  in  either  direction  can  be  lost,  reordered,  corrupted,  or  duplicated. 
Given  such  an  environment,  the  protocol  is  supposed  to  ensure  correct  delivery  of  the  messages. 

The  protocol  uses  a  conventional  positive-acknowledgment,  retransmission-on-time-out  technique, 
and  the  receiver  and  transmitter  both  maintain  windows  of  messages.  The  transmitter’s  window 
contains  messages  sent  but  not  yet  acknowledged.  Similarly,  the  receiver  can  buffer-ahead 
messages  received  out  of  order  (up  to  some  limit),  awaiting  receipt  of  the  next  expected  message. 

The  Affirm  specification  of  the  Data  Transfer  Protocol,  as  well  as  a  proposed  safety  invariant  and 
documentation  of  its  partial  proof,  are  included  in  [49]. 

6.2.  Transport  Service 

The  transport  service  represents  a  protocol  layer  allowing  many  users  to  exchange  data.  Users  are 
identified  by  port  addresses.  In  order  to  exchange  messages,  users  must  first  establish  a  connection 
between  themselves  by  appropriate  requests  to  the  system;  once  this  is  done,  users  may  exchange 
data  in  both  directions  independently. 

The  exchange  itself  functions  as  in  the  data  transfer  protocol  above,  but  is  controlled  by  the 
receiving  end  (in  each  direction),  through  the  use  of  explicit  credits,  i.e.,  permission  to  send  one  or 
more  messages.  Once  users  are  done  communicating,  they  ask  the  system  to  disconnect  the 
established  connection. 
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We  have  specified  a  transport  service  (but  not  the  protocol  implementing  the  service),  and  proved 
several  properties  about  the  specification.  The  specification  is  done  in  two  levels.  The  lower  level 
describes  gas  half-duplex  connection  that  knows  about  the  connection  status  at  both  ends.  The 
upper  level  uses  Jwg  such  half-duplex  connections,  one  for  each  direction,  with  a  shared  connection 
status,  thus  modeling  a  full-duplex  connection  between  each  pair  of  users.  This  division  permits  the 
separation  of  addressing  properties  from  data  transfer  properties. 

Properties  proved  about  this  specification  show  that  normal  sequences  of  connection  setup  and 
data  transfer  commands  will  have  their  anticipated  effects.  An  interesting  detail  discovered  during 
these  proofs  was  that  the  specification  precluded  a  user  from  establishing  a  connection  with  itself. 

Complete  details  of  the  specification  and  proven  properties  may  be  found  in  [41]. 

6.3.  Selective  Repeat  Transport  Protocol 

A  transport  protocol  similar  to  Stenning's  is  specified  in  [3].  It  involves  the  transfer  of  messages 
between  a  sender  and  a  receiver  over  an  unreliable  medium  (it  may  lose  messages,  but  not  reorder 
them).  The  sender  has  a  window  of  messages  that  have  been  sent  but  not  yet  acknowledged.  If  the 
acknowledgment  does  not  arrive  within  a  certain  (fixed  but  arbitrary)  time,  the  message  is  considered 
to  have  been  lost  and  is  retransmitted.  This  protocol  is  proven  to  be  partially  correct  with  respect  to 
the  property  of  "correctly  transferring  data  across  the  medium." 

Progress  properties  and  their  characterization  in  Affirm  are  examined  in  [2].  In  particular,  an 
extension  of  Floyd's  "well-founded  set"  method  [8]  is  used  to  show  the  termination  of  a  data  transfer 
protocol. 

6.4.  Connection  Establishment  Protocol 

A  protocol  to  provide  the  kind  of  connection-establishment  service  described  in  Section  6.2  has 
been  specified  in  [43].  The  protocol  modeled  in  that  paper  is  the  three-way  handshake  used  in  the 
ARPANET  TCP  algorithm.  Although  the  protocol  has  not  been  verified  against  a  complete  service 
specification,  several  interesting  properties  have  been  proved.  Work  is  continuing. 
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7.  PROBLEMS  AND  EXTENSIONS 

While  we  feel  that  we  have  had  considerable  success  in  handling  protocols  with  Affirm,  several 
areas  need  further  work.  In  this  section  we  briefly  discuss  problems  encountered  and  possible 
extensions. 

7.1 .  Composition  of  Specifications 

Given  that  a  protocol  layer  is  composed  of  several  interacting  stations,  it  is  reasonable  to  specify 
the  behavior  of  each  station  separately,  i.e.,  by  presenting  its  local  view  of  the  rest  of  the  system  [42]. 
In  a  second  step,  these  several  local  views  could  be  combined  to  specify  the  overall  behavior  of  the 
layer. 

At  present,  the  techniques  described  in  the  previous  sections  do  not  allow  the  straightforward 
composition  of  such  specifications;  all  specifications  thus  far  have  described  systems  from  a  global 
reference  point. 

7.2.  Concurrency 

A  protocol  layer  supports  several  users,  and  may  receive  simultaneous  requests  for  service  from 
them  (e.g.,  one  side  is  sending  a  long  message  while  the  other  acknowledges  a  previous  message).  A 
fully  adequate  specification  method  should  allow  for  concurrent  operations  for  both  service 
specifications  and  protocol  specifications.  Furthermore,  since  the  stations  composing  the  layer 
operate  independently,  the  verification  method  must  be  able  to  analyze  systems  with  concurrently 
executing  components. 

A  basic  assumption  of  most  state  transition  models  is  that  the  transitions  are  atomic,  serial 
operations.  This  assumption  is  carried  over  to  the  Affirm  specifications  where  the  axioms  define  the 
effects  of  each  atomic  operation  (constructor  function).  However,  this  limitation  is  not  as  serious  as  it 
might  at  first  appear,  because  by  defining  operations  with  a  small  enough  grain  the  assumption  of 
atomicity  is  reasonable.  For  systems  with  several  independent  components,  the  effect  of 
concurrency  can  be  approximated  by  considering  all  possible  interleavings  of  the  operations  of  each 
component. 
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7.3.  Exceptions 

The  main  purpose  of  a  protocol  specification  is  to  define  allowed  or  normal  sequences  of 
operations  and  their  effects.  Unfortunately,  it  is  a  fact  of  life  in  the  protocol  world  that  users 
occasionally  issue  invalid  commands,  and  even  protocol  stations  send  inappropriate  messages  to 
each  other.  Thus  it  is  inadequate  to  state  merely  that  the  protocol  behavior  is  undefined  for  invalid 
inputs,  or  that  some  unspecified  party  is  responsible  for  guaranteeing  that  inputs  are  valid.  A  richer 
vocabulary  for  specifying  the  handling  of  such  exceptional  conditions  should  be  supported, 
including: 

1.  ignore  invalid  inputs  (i.e.,  they  have  no  effect), 

2.  refect  them  (i.e.,  they  have  no  effect,  but  an  error  indication  is  returned  to  the  requesting  party), 
and 

3.  enter  an  error- recovery  portion  of  the  protocol. 

Axiomatic  specification  methods  have  difficulties  with  (2)  and  (3),  and  the  example  protocol 
specifications  prepared  in  Affirm  to  date  have  been  limited  to  ignoring  invalid  inputs,  or  simply  not 
defining  the  results.  Several  methods  to  extend  axiomatic  techniques  to  handle  exceptions  have 
been  proposed,  but  we  have  not  yet  determined  the  best  way  to  proceed  in  Affirm. 

7.4.  Specification  and  Verification  of  Systems  with  More  than  Two 
Interacting  Entities 

So  far,  we  have  considered  only  protocols  that  involve  essentially  two  interacting  entities  over  a 
transmission  medium.  This  covers  a  large  number  of  protocols  in  current  use.  Nevertheless,  there 
are  protocols  involving  more  than  two  interacting  entities  (e.g.,  routing  in  packet-switching  networks). 
It  appears  that  the  techniques  discussed  in  this  report  can  be  applied  to  the  specification  of  these 
protocols  as  well,  but  we  have  not  done  it. 

As  one  would  expect,  there  is  a  combinatorial  explosion  on  the  number  of  possible  states  of  the 
system.  It  is  at  this  point  that  the  ability  to  decompose  the  overall  system  description  into  the 
description  of  its  components  becomes  crucial,  since  it  allows  the  analysis  of  the  behavior  of  the 
system  through  the  analysis  of  the  behavior  of  its  components.  We  are  investigating  extensions  of  our 
techniques  to  handle  such  situations. 
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7.5.  Higher  Level  Protocols 

The  main  application  of  formal  specification  methods  to  protocols  has  been  at  the  data  transfer 
level,  where  the  first  concerns  are  overcoming  message  loss,  damage,  and  reordering.  Much  less 
work  has  been  done  on  formally  specifying  higher  level  protocols  that  focus  more  on  translation  into 
and  out  of  canonical  forms  (e.g.,  a  virtual  terminal  or  file).  Furthermore,  the  operations  to  be  specified 
are  more  specialized  to  the  area  of  concern  of  the  protocol  (e.g.,  graphics,  terminal  handling,  speech 
compression)  than  to  general  data  transfer.  It  remains  to  be  seen  whether  the  same  methods  are 
applicable  at  these  higher  levels,  or  whether  a  new  set  of  abstractions  (e.g.,  involving  canonical 
forms)  will  be  more  suitable. 
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8.  CONCLUSION 

We  have  chosen  to  combine  the  state  transition  model  and  abstract  data  type  approaches  for 
several  reasons.  First,  we  have  a  strong  methodology  and  a  rapidly  evolving,  powerful  supporting 
tool:  Affirm.  A  natural  question  is  whether  such  a  methodology  can  accommodate  a  diverse  set  of 
formalisms  and  modeling  methods. 

This  question  first  arose  in  conjunction  with  a  toy  Security  Kernel  [29],  where  we  were  presented 
with  a  state  transition  specification  of  an  operating  system  kernel  with  operations  such  as 
SwapProcesses  and  RaiseBlockLevel.  It  was  quite  natural  to  represent  the  specification  as  a  data 
type  and  then  do  an  induction  proof  of  an  important  invariant  about  relative  block  and  process  levels. 

We  then  applied  the  same  method  to  protocols  and  have,  on  the  whole,  been  quite  satisfied.  Its 
limitations  are  touched  upon  in  Chapter  7,  but  within  these  limits  we  have  conducted  a  broad 
exploration  of  several  protocol  issues. 

All  methods  have  limitations.  Some  of  the  limitations  of  other  methods  are  handled  nicely  in  our 
approach.  For  example,  we  have  no  problem  with  unbounded  objects,  which  cause  difficulties  for 
finite-state  modeling  approaches.  However,  we  lack  the  decision  ability  of  algorithms  based  on  finite- 
state  exploration  and  its  ability  to  simply  reveal  errors. 

Another  advantage  of  our  approach  is  the  capability  to  execute  specifications:  axioms  have  a 
natural  rewriting  rule  representation  that  we  exploit.  That  is,  we  can  take  a  set  of  axioms,  plug  in 
special  values,  and  see  where  the  rewriting  leads.  The  determinism  and  executability  of  axioms  is  an 
aid  in  evaluating  the  accuracy  of  specifications,  independent  of  their  ability  to  support  proofs.  This 

[  advantage  has  been  exploited  in  [43]. 

I 

|  Our  method  also  leads  naturally  from  specification  to  verification,  using  the  standard  data  type 

!  induction  methods.  No  further  mechanisms  were  needed  to  adjust  Affirm  to  state  transition 

!  specifications,  although  a  "front-end"  to  handle  our  stylized  type  specifications  would  be  useful. 

f 

•  In  conclusion,  a  basis  has  been  laid  for  further  steps  toward  practical  specification  and  verification 

of  not  just  protocols,  but  also  of  any  system  expressible  as  a  state  transition  machine.  Experience 
indicates  that  real  protocols  can  be  handled  [42].  The  major  remaining  task  is  to  consolidate 
techniques  for  proving  progress  and  liveness. 


APPENDIX  I 

DATA  TRANSFER  SERVICE  SPECIFICATION 

The  service  specification  uses  three  auxiliary  data  types:  ControlState,  a  simple  enumerated  type 
with  four  constants  (specified  in  this  appendix),  Message,  a  type  about  which  we  make  no 
assumptions  (except  the  standard  one:  there  is  an  equality  operation  on  the  type),  and 
QueueOtMessage,  an  instantiation  of  the  generic  QueueOfElemType  type  from  the  Affirm  type  library 
[50;Vol.lll]. 


The  following  text  is  in  exactly  the  form  in  which  it  would  be  submitted  to  the  system,  except  for  the 
use  of  multiple  fonts.  In  particular,  the  "no  change"  axioms  deleted  from  the  axiom  sets  of  the 
stylized  state  machine  description  on  page  15  are  included  here, 
type  SimpleMessageSystem, 

need*  typ«*  Massage.  QueueOtMessage,  ControlState; 

declare  s:  SimpleMessageSystem; 

declare  m:  Message; 

interface  Statefs);  ControlState; 

interfaces 

Sent(a),  Received(s),  Buffers):  QueueOfMessage; 
interfaces 

InitializeService.  UaerSendfs,  m),  Send  Completes),  UserReceive(s),  ReceiveComplete(s) :  SimpleMessageSyatom; 
interface  Inductions):  Boolean; 

axioms 

State(UserSend(a,  m))  «  ■  if  Stats(s)  ■  Ready  To  Send 
then  Sending 
eiae  State(s), 

State(SendComplete(s))  »  ■  if  State(s)  ■  Sending 

then  ReadyToReceive 
eiae  State(s), 

State(UserReceive(s))  •  ■  If  State(s)  •  ReadyToReceive 
then  AcMng 
else  States], 

State(ReceiveComplete<s))  *  -  If  Statefs)  *  Acking 

then  ReadyToSend 
eiae  State(s), 

State(lnitialixeServlce)  «  «  ReadyToSend; 
axioms 

Sent(UserSend(t,  m))  >  •  H  State(a)  «  ReadyToSend 
then  Sent(s)  Add  m 
else  Sent(s), 

Sent(SendComplete(s))  *  ■  Sent(s), 

Sent(UserReceive(s))  *  -  Sent(s), 

Sent(ReceiveComplete(s))  ■  •  Sent(s), 

Sen t( InitializeService)  «  «  NewQueueOfMessage; 
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axioms 

R«ceiv0d(UaerSend(s,  m))  «  »  Racsived(s), 

Received(SendComplete<s))  »  *  Rscsivsd(s), 

Received(UeefReceive(»))  ■  «  if  SUto(s)  »  ReadyToReceive 

then  Received(s)  Add  Front(Buffer(a)) 
else  Received(s), 

Received(ReceiveComplete<s))  «  »  Received(s), 

Received(lnitializeService)  «  »  NewQueueOf  Message; 

axioms 

Buffer(UaerSend(s,  m))  »  «  H  Statefs)  »  ReadyToSend 
then  Buffer(s)  Add  m 
else  Butfer(s), 

Buff er(Send Complete^))  »  »  Buffer(s), 

Buffer(UaerRece<ve<a))  «  »  Buffer(a), 

Buffer  (ReceiveComplete(s))  *  *  if  State(s)  =  Ac  king 

then  Remove(Buffer(s)) 
else  Buffer(a), 

Buffer(lnitializeSe(vice)  »  «  NewOueueOfMessage; 

schema  lnductk>n{s) 

»  a  caaea(Prop(lnitializeService), 

all  s,  m  (IH(a)  imp  Prop(UserSend(a,  m))}, 
all  a  (IH(s)  imp  Prop<SendComplete(a))). 
all  a  (IH(s)  imp  Prop(UaerReceive(a))), 
all  a  (IH(s)  imp  Prop<ReceiveCompiete(s)))); 
end  {SimpleMessageSystem} ; 

type  ControlState,  {An  m numerated  type,  with  tour  distinct  constants} 

declare  ce:  ControlState; 

interfacee 

ReadyToSend,  Sending,  ReadyToReceive,  Acking;  ControlState; 
axioms  {Thoso  axioms  state  that  all  the  constants  ot  this  type  are  distinct .1 
cs  a  CS  ■  ■  TRUE, 

ReadyToSend  *  Sending  »  a  FALSE, 

ReadyToSend  a  ReadyToReceive  a  a  FALSE, 

ReadyToSend  a  Acking  a  a  FALSE, 

Sending  a  ReadyToSend  a  a  FALSE, 

Sending  a  ReadyToReceive  a  a  FALSE, 

Sending  a  Acking  a  a  FALSE, 

ReadyToReceive  a  ReadyToSend  a  a  FALSE, 

ReadyToReceive  a  Sending  a  a  FALSE, 

ReadyToReceive  a  Acking  a  a  FALSE, 

Acking  a  ReadyToSend  a  a  FALSE, 

Acking  a  Sending  a  a  FALSE, 

Acking  a  ReadyToReceive  a  a  FALSE; 
end  { ControlState } ; 

type  Message,  (A  type  about  which  we  make  the  absolutely  minimal  assumptions:  there  Is  an  equality  relation.} 

declare  m;  Message; 
axiom  m  a  m  a  a  TRUE; 
end  {Message ; 
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APPENDIX  II 

THE  PROTOCOL  REPRESENTATION 

These  axioms  are  in  exactly  the  form  in  which  they  would  be  submitted  to  Affirm;  see  Appendix  I 
for  an  explanation  of  how  their  form  differs  from  the  earlier,  stylized,  presentation.  The  auxiliary  types 
Message,  Packet,  Medium,  Bit,  and  QueueOfMessage  are  also  listed  here, 
type  ABProtocol; 

needs  types  Message,  Packet,  QueueOfMessage,  QueueOfPacket,  Medium,  Bit; 

declare  s,  as:  ABProtocol; 
declare  m,  mm:  Message; 
declare'med:  Medium; 
declare  packetq:  QueueOfPacket; 
declare  pkt:  Packet; 

interfaces 

Sent(a),  Received(s),  Text( packetq):  QueueOfMessage; 
interfaces 

SenderT oReceivert  s) .  ReceiverToSender(s):  Medium; 
interfaces 

ReceiverBuffer(a) ,  Pending(s):  QueueOfPacket; 
interfaces 

InitialSequenceNumtMr,  SSN(s),  RSN(s):  Bit; 
interfaces 

InitializeProtocol,  Dei  (verts),  ProtocolSend(s,  m),  ReceivePacket(s), 

ReceiveAck(a),  Retrsnsmtt(s),  LoeePacket(s),  LoseAck(s):  ABProtocol; 

interfaces 

NormalForm(s),  lnduction(s):  Boolean; 
axiom  s  ■  S  ■  ■  TRUE, 
axioms 

Sen t(Pr otoc otSend{s,  m))  a  a  if  Pending(s)  ■  NewQueueOfPacket 

then  Sends)  Add  m 
else  Sent(s), 

Sent(ReceivePacket(i))  •  «  Sent(s), 

Sen t( Receive Ack(a))  «  «  Sant(a), 

Sent(Deliver(s))  .  .  Sends), 

Sent(Retranamit(s))  ■  ■  Sends), 

SendLoeePackeds))  -  «  Sends), 

SandLoaeAck(s))  ■  «  Sends), 

SendlnitlalizaProtocoO  *  -  NewQueueOf Message; 
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axiom* 

Received(ProtocolSend(s,  m))  *  *  Received(s), 

Receivsd(ReceivePacket(s))  =  «  Received(s), 

Received(ReceiveAck(s))  *  ■  Received(s), 

Received(Deiiver(a))  *  =  H  ReceiverBuffer(s)  =  NewQueueOfPacket 
then  Received(s) 

else  Received(s)  Add  Text(Front(ReceiverBuffer(s)», 

Received{Retransmit(s))  «  =  Received(s), 

Received(LoaePacket(s))  =  =  Received(s), 

Received(LoaeAck(a))  =  »  Received(s), 

Received(lnitializeProtocol)  =  =  NewQueueOf  Message, 

axiom* 

Text(NewOueueOfPacket)  *  =  NewQueueOf  Message, 

Text(packett)  Add  pkt)  =  =  Text(packetq)  Add  Text(pkt); 

axioms 

SenderToReceiver(Protocol Send (s ,  m))  =  =  if  Pending(s)  =  NewOueueOf Packet 

then  Transmit(SenderToReceiver(s),  MakePacket(m,  SSN(s))) 
else  SenderToReceiver(s), 

SenderToReceiver(ReceivePacket(s))  =  =  Receive(SenderT  oReceiver(s)). 

SenderToReceiver(ReceiveAck(s))  =  =  SenderToReceiver(s), 

SenderToReceiver(Deliver(s))  s  =  SenderToReceiver(s) , 

SenderToReceiver(Retransmit(s))  =  =  if  Pending(s)  =  NewQueueOfPacket 

then  SenderToReceiver{s) 

else  Transmit{SenderToReceiver(s),  Front(Pendino(s))), 
SenderToReceiver(LosePacket(s))  =  =  Receive(SenderT  oReceiver(s)), 

SenderToReceiver(LoseAck(s))  =  *  SenderToReceiver(s), 

SenderToReceiver(lnitializeProtocol)  m  *  InitializeMedium; 

axiom* 

ReceiwerToSender(ProtocolSend(s.  m))  =  =  ReceiverToSender(s), 

ReceiverT oSender(ReceivePacket(s))  =  =  if  SenderToReceiver(s)  -  =  InitializeMedium 

and  Receive  rBuffer(s)  =  NewQueueOfPacket 
and  RSN(s)  -  =  Seq(Front(SenderToReceiver(s))) 
then  T ransmit(ReceiverT oSender(s),  Front(SenderToReceivef(s)» 
else  ReceiverT oSender(s) , 

ReceiverToSender(ReceiveAck(s))  =  =  Receive(ReceiverToSender(s)), 

ReceiverT oSender(Deliver(s))  =  =  if  ReceiverBuffer(s)  =  NewQueueOfPacket 

then  ReceiverToSender(s) 

else  Transmit(ReceiverToSender(s),  Front(ReceiverBuffer(8))), 
ReceiverToSender(Retransmit(s))  =  -  ReceiverToSender(s), 

ReceiverToSender(LosePacket(s))  =  =  ReceiverToSender(s), 

ReceiverT  oSender(LoseAck(s))  =  =  Receive(ReceiverToSender(s)), 

ReceiverToSender(lnitializeProtocol)  =  =  InitializeMedium; 

axiom* 

ReceiverBuffer(ProtocoiSend(s,  m))  *  *  ReceiverBuffer(s), 

ReceiverBuffer(ReceivePacket(s))  =  =  if  Seq(Front(SenderToReceiver(s)))  «  RSN(») 

and  SenderToReceiver(s)  -*  InitializeMedium 
then  NewQueueOfPacket  Add  Front(SenderT oReceiver(s)) 
else  Receiv8rBuffer(s), 

ReceiverBuffer(ReceiveAck(s))  *  »  Receive rBuffer(s) , 

Receive rBuffer(Deliver(s))  »  -  NewQueueOfPacket. 

Receiver8uffer(Retransmit(s))  «  ■  ReceiverBuffer(s). 

ReceiverBuffer(LosePacket(s))  •  ■  ReceiverBuffer(s), 

ReceiverBuffer(LoseAck(s))  >  -  ReceiverBuffer(*), 

ReceiverBuffer(lnitialize Protocol)  »  «  NewQueueOfPacket; 


THE  PROTOCOL  REPRESENTATION 


axiom* 

Panding(ProtocolSand(A  m))  ■  ■  if  Pending(s)  *  NawOuaueOf  Packet 

then  NewQueueOfPaeket  Add  MakePacket(m,  SSN(s)) 
aiaa  Pendinofs), 

Pending(Rec*iv*Packet(s))  ■  «  Pending(s), 

Pending(Receiv*Ack(s))  =  «  if  Seq(Front(RecaivarToSendar(s)))  >  SSN(s)  and  ReceiverToSender(s)  -  «  InitializeMedium 
then  NewQueueOfPaeket 
else  Pending*), 

Pending!  Delivef(s))  «  «  Pending(s), 

PendingfRetransmitfs))  *  ■  Pending(s), 

Pending(LoaePacket(a))  »  *  Pending<a), 

Pending LoaeAck(s))  *  «  Pending<a), 

Pending(initializeProtocol)  *  =  NewQueueOfPaeket; 

axioms 

SSN(ProtocoiSend(s,  m))  *  =  SSN(a), 

SSN(ReceivePacket(s))  «  »  SSN(a), 

SSN(ReceiveAck(a))  *  *  if  Seq(Front(ReceiverToSender(s)))  =  SSN(s)  and  ReceiverToSender(s)  -  =  InitializeMedium 
then  ~SSN(s) 
else  SSN(s), 

SSN(Oeiiver(s))  «  -  SSN(s), 

SSN(Retransmit(s))  =  *  SSN(s), 

SSN(LosePacket(s))  ■  ■  SSN(s), 

SSN(LoseAck(a))  «  =  SSN(s), 

SSN(lnitializeProtocol)  *  *  InitialSequenceNumber; 

axiom* 

RSN(ProtocolSend(s,  m))  =  =  RSN(s), 

RSN(ReceivePacket(s))  =  »  H  Soq(Front(SenderToReceiver(s)))  *  RSN(s>  and  SenderToReceiverfs)  ~  =  InitializeMedium 
then  -RSN(s) 
else  RSN(s). 

RSN(ReceiveAck(s))  »  *  RSN(s), 

RSN(Oeliver(s))  «  »  RSN(s), 

RSN(Retransmit(s))  »  »  RSN(s), 

RSN(LosePacket(a))  «  «  RSN(s), 

RSN(LoseAck(s))  >  >  RSN(s), 

RSN(lnitializeProtocol)  *  *  InitialSequenceNumber; 

schema 

NormalForm(s)  «  «  casea(Prop(lnitializeProtocol), 

all  as,  mm  (Prop(ProtocolSend(ss,  mm))), 

all  as  (Prop(ReceivePacket(ss))), 

all  as  (Prop<ReceiveAck(ss))), 

all  as  (Prop(Dellver(ss))), 

all  as  (Prop(Retransmit(ss))), 

all  as  (Prop{LoaePacket(ss))), 

all  as  (Prop(LoaeAck(ss)))), 

Inductions)  *  =  cases(Prop(lnitializeProtocol)l 

all  as,  mm  (IH(ss)  imp  Prop(ProtocolSend(ss,  mm))), 
all  as  (lH(ss)  imp  Prop(RecelvePacket(ss))), 
all  as  (IH(ss)  imp  Prop(ReceiveAck(sa))), 
all  as  (IH(ss)  imp  Prop(Deliver(ss))), 
all  as  (IH(ss)  imp  Prop(Retran3mit(ss))), 
all  ss(IH(as)  imp  Prop(LosePacket(sa))), 
all  aa  (IH(aa)  imp  Prop<LoseAck(ss)))); 
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end  { ABProtocol } ; 


THE  PROTOCOL  REPRESENTATION 


type  Medium, 

nHdi  type  Packet; 

declare  m.  ml,  m2:  Medium; 
declere  pkt,  pktl,  pkt2:  Packet; 

interfaces 

InitializeMedium,  Transmit(m,  pkt),  Receive(m),  Lose(m):  Medium; 
interface  Front(m):  Packet; 
interfacee 

Empty(m),  pkt  in  m,  induction(m):  Boolean; 
infix  in; 
axioms 

m  a  m  *  s  TRUE, 

Transmit(m,  pkt)  -  InitializeMedium  a  a  FALSE, 

InitializeMedium  a  Transmit(m,  pkt)  a  a  FALSE, 

Transmit(m1,  pktl)  a  Transmit(m2,  pkt2)  a  =  ((ml  a  m2)  and  (pktl  a  pkt2)); 
axioms 

Receive(lnitializeMedium)  a  a  InitializeMedium, 

Receive(Transmit(m,  pkt))  a  a  if  m  a  InitializeMedium 

then  InitializeMedium 

else  Transmit(Receive(m),  pkt); 


axiom  Lose(m)  a  a  Receive(m); 

axiom  Front(Transmit(m,  pkt))  a  a  if  m  a  InitializeMedium 

then  pkt 
else  Front(m); 

axiom  Empty(m)  a  a  (m  a  InitializeMedium); 
axioms 

pkt  in  InitializeMedium  a  a  FALSE, 

pkt  in  Transmit(m,  pktl)  a  a  ((pkt  a  pktl)  or  pkt  in  m); 

schema  Induction(m) 

a  a  cases(Prop(lnitializeMedium), 

all  m,  pkt  (IH(m)  imp  Prop(Transmit(m,  pkt)))); 


end  { Medium } ; 
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type  Bit, 

declare  b,  bl,  b2:  Bit; 

interfaces 

on,  off,  -bl:  Bit; 

interface  NormalForm(b):  Boolean; 

axiom  — b  ■  *  b; 

axioms 

bxb  «  x  TRUE, 
on  x  ott  x  =  FALSE, 
oft  «  on  =  x  FALSE, 
bl  x  ~b2  =  x  bl  -  x  b2, 

-bl  x  b2  .  =  bl  -  a  b2; 

schema  NormalFormfb)  a  a  cases(Prop{on),  Prop<off)); 
end  {Bit) ; 


type  Message,  { A  type  about  which  we  make  the  absolutely  minima!  assumptions.-  there  &  an  equality  relation.) 

declare m:  Message; 
axiom  mam  a  *  TRUE; 
end  { Message } ; 


type  Packet, 

needs  types  Message,  Bit; 

declare  pkt:  Packet; 
declared,  b1,b2:  Bit; 
declare  m,  ml,  m2:  Message; 

interface  MakePacket(m.  b):  Packet; 

interface  Seq(pkt):  Bit; 

interface  Text(pkt):  Message; 

axioms 

pkt -pkt  x  a  TRUE, 

MakePacket<m1,  bl)  a  MakePacket(m2,  b2)  x  -  ((ml  x  m2)  and  (bl  -  b2)); 
axiom  Seq(MakePacket(m,  b))  x  -  b; 
axiom  Text(MakePacket(m,  b))  ■  *  m; 
end  {Packet) ; 


THE  PROTOCOL  REPRESENTATION 


type  QueueOfMessage, 

need*  type  Message; 

declare  q,  ql,  q2,  qq:  QueueOfMessage; 
declare  i,  il,  i2,  ii:  Message; 

interfaces 

NewQueueOf Message,  q  Add  i,  Remove(q),  Append(q1 ,  q2),  que(i):  QueueOfMessage; 
infix  Add; 

interfaces 

Front(q),  Back(q):  Message; 
interfaces 

NormalForm(q),  Induction(q),  i  in  q:  Boolean; 
infix  in; 

axioms 

q  =q  =  =  TRUE, 

q  Add  i  s  NewQueueOf  Message  =  =  FALSE, 

NewQueueOf  Message  =  q  Add  i  =  =  FALSE, 
ql  Add  il  =  q2  Add  i2  =  =  ((ql  =q2)  and  (il  =  i2»; 

axioms 

Remove(NewQueueOfMessage)  =  =  NewQueueOfMessage, 

Remove(q  Add  i)  =  =  if  q  =  NewQueueOfMessage 
then  q 

else  Remove(q)  Add  i; 

axioms 

Appendfq,  NewOueueOfMessage)  =  =  q, 

Append(q,q1  Add  il)  a  =  Append(q,  q  1 )  Add  i  1 ; 

axiom  que(i)  =  =  NewQueueOfMessage  Add  i; 

axiom  Front(q  Add  i)  a  =  if  q  =  NewQueueOfMessage 
then  i 

else  Front(q); 


axiom  Back(q  Add  i)  =  *  i; 
axioms 

i  in  NewOueueOfMessage  =  a  FALSE, 
i  in  (q  Add  il)  =  *  (i  in  q  or  (i  =  il)); 

rulelemma  Append(NewQueueOf Message,  q)  =  =  q; 

schema 

NormalForm(q)  a  a  cases(Prop(NewOueueOf Message), 
all  qq.  ii  (Prop(qq  Add  ii))), 

Induction(q)  >  a  cases(Prop(NewQueueOfMessage), 

all  qq.  ii  (IH(qq)  imp  Prop(qq  Add  «))); 


end  { QueueOfMessage } ; 


APPENDIX  III 

SERVICE  AXIOMS  -  PROTOCOL  THEOREMS 

This  appendix  contains  the  correspondence  between  the  service  and  protocol  specifications  of  the 
Alternating  Bit  protocol,  and  lists  the  theorems  generated  as  part  of  the  job  of  proving  that  the 
protocol  implements  the  service.  These  theorems  have  been  proved  using  Affirm.  The  proofs  are 
documented  in  [51]. 


III. 1.  The  Correspondence  between  the  Service  and  the  Protocol 

declare  s:  ABProtocol; 
declare  m:  Message; 

interface  rep(s):  ABProtService; 

1.  InitializeService  =  =  rep(lnitializeProtocol) 

2Sentservic^eP(S))  =  =  ^Vtocolfe) 

3.  Received^^repts))  =  =  Received  ^(s) 

4.  Buffer(rep(s))  =  =  Text(Front(Pending(s))) 

5.  State(rep(s))  =  =  if  InSI  (s) 

then  ReadyToSend 
else  if  lnS2(s) 

then  Sending 
else  if  lnS3(s) 

then  ReadyToReceive 
else  Acking 

6.  UserSend(rep(s),  m)  =  =  rep(ProtocolSend(s,  m)> 

7.  Receive(rep(s))  =  =  rep(Deliver(s)) 

8.  SendComplete(rep(s)) 

=  =  rep({LosePacketLoseAckRetransmitReceivePacketReceiveAck}*  (s)) 

9.  ReceiveComplete(rep(s)) 

=  =  rep({LosePacket  LoseAck  Retransmit  ReceivePacket,  ReceiveAck}*  (s)) 


III. 2.  Correspondence  of  States  Between  Service  and  Protocol 

The  four  states  in  the  service  specification,  ReadyToSend,  Sending,  ReadyToReceive,  and  Acking, 
correspond  to  four  states  in  the  protocol  specification,  labeled  Si,  S2,  S3,  and  S4.  The  predicates  in 
the  protocol  specification  defining  these  states  are  defined  in  Affirm  as  follows. 

lnS1(s)  { ReadyToSend } 

s  s  (  Pending(s)  *  Me wOueueOf Packet 
and  ReceiverBuffer(s)  =  NewQueueOf  Packet 
andSent(s)  a  Received(s) 
and  PktsO)d(s,  SenderToReceiver(s)) 
and  PktsO<d(s,  ReceiverToSender(s)) 
and  RSN(s)  .  SSN(s)) 


% 
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lnS2<s)  { Sending } 

>>  (  Pending(a)  -  *  NewQueueOfPacket 
and  Receiver8uffer(s)  =  NewQueueOf  Packet 
and  Sent(s)  =  Received(a)  Add  Text(Front(Pending(s))) 
and  PktsCurrentOrOtd(s,  SenderToReceiver(s)) 
and  PktsOld{s,  ReceiverToSender(s)) 
and  RSN(s)  =  SSN(s)) 

lnS3(s)  { ReadyToReceive } 

=  =  (  Pending^ s)  -  =  NewOveueOf  Packet 
and  ReceiverBuffer(a)  =  Pending(s) 
and  Sent(s)  =  Received(s)  Add  Text(Front(Pending(s))) 
and  PktsCurrent(s,  SenderToReceiver(s)) 
and  PktsOld(s,  ReceiverToSender(s)) 
and  RSN<s)  -  =  SSN(s)) 

lnS4(s)  { Aching } 

s  ■  (  Pending(s)  ~  *  NewQueueOfPacket 
and  ReceiverBuffer(s)  =  NewQueueOf  Packet 
and  Sent(s)  =  Received(s) 
and  PktsCurrent(a,  SenderToReceiver(s)) 
and  PktsCurrentOK>d(s,  ReceiverToSender(s)) 
and  RSN(s)  -  =  SSN(s)) 


III. 3.  Example:  Mapping  Two  Service  Axioms  into  Protocol  Theorems 

Service  axiom 

Received  .  (UserSend(S,  m))  =  «  Received,.  (S) 

service  service 

use  S  =  rep(  s) 

Received^^UserSendfrepfs),  m))  =  Received^^repfs)) 
use  6 

Receivedsefvice(rep(ProtocolSend(s,  m)))  =  Receivedservjce(rep(s)) 
use  3 

ReceivedprotocoI(ProtocolSend{s,  m))  =  Receivedprofoco|(s) 


Service  axiom 
Sent  .  (UserSend(S,  m)) 


ifState(S)  =  ReadyToSend 
then  Sent^JS)  Add  m 
eiseSent^rvicefS) 


useS  »  rep(s) 

Sent  .  (Use rSend(rep(s),  m)) 


ifStat  e(rep(s))  =  ReadyToSend 
then  Sentservjce(rep(s))  Add  m 
else  Sent9ervjce(rep(s)) 
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use  6 

Sen^service(Ae^(Pr°t0C°ISend(si  m)))  =  =  if  State(rep(s))  =  ReadyToSend 

then  Sent^^frepfs))  Add  m 
else  Sent  .  (rep(s)) 


use  2 

^nVotoco.<Pr0tOCOlSend<S'  = 


=  if  State(rep(s)) 
then  Sent, 


else  Sent 


protocol, 

protocol 


ReadyToSend 
(s)  Add  m 
(s) 


use  5 

Sentpr0tocol(Pr0tOCOlSend(S' m))  = 


=  if  InSI  (s) 

then  Sentprotocol(s)  Add  m 
else  Sentprotoco|(s) 


III. 4.  Effects  on  State  Variables  by  User  Operations 

{for  the  Send  operation:} 

theorem  SS,  Sent(ProtocolSend(s,  m))  =  if  InSI (s) 

then  Sent(s)  Add  m 
else  Sent(s); 

theorem  RS,  Received(ProtocolSend(s,  m))  =  Received(s); 

theorem  BS.  Text(Pending(ProtocolSend{s,  m)))  =  if  InSI (s) 

then  Text(Pending(s))  Add  m 
else  T  ext(Pendingts)); 


{for  the  Receive  operation:} 
theorem  SR,  Sent(Oeliver(s))  =  Sent(s); 


theorem  RR,Received(Detiver(s»  =  H  lnS3(s) 

then  Received(s)  Add  Front(Text(Pending(s))) 
else  Received(s); 


theorem  BR,  Text(Pending(Deliver(s)))  =  Text(Pending(s)); 


{for  the  InltlallzaProlocol  operation:} 

theorem  SI,  Sent(lnitializeProtocol)  =  NewQueueOfMessage; 

theorem  fl/,  Received(lnitializeProtocol)  *  NewQueueOfMessage: 

theorem  81,  Text(Pending(lnitializeProtocol))  *  NewQueueOfMessage; 

theorem  Tl,  InSl(lnitializeProtocol); 


EFFECTS  ON  STATE  VARIABLES  BY 


111.5.  Effects  on  State  Variables  bv  Spontaneous  Operations 

{for  the  Sent  state  variable:} 
theorem  SentSpont, 

Sent(ReceiveAck(s))  =  Sent(s) 
and  Sent(ReceivePacket(s))  =  Sent(s) 
and  Sent(Retransmit(s))  *  Sent(s) 
and  Sent(LosePacket(s))  =  Sent(s) 
and  Sent(LoseAck(s))  3  Sent(s); 


{for  the  Received  state  variable:} 
theorem  ReceivedSpont, 

Received(ReceiveAck(s))  =  Received(s) 
and  Received(ReceivePacket(s))  =  Received(s) 
and  Received(Retransmlt(s))  =  Received(s) 
and  Received(LosePacket(s))  3  Received(s) 
and  Received(LoseAck(s))  =  Received(s); 


{for  the  Buffer  state  variable:} 
theo  rem  BulferSpontl , 

~lnS4(s) 

imp  Pending(ReceiveAck(s))  =  Pending(s)  and  ~lnS4(ReceiveAck{s)) 
and  Pending(ReceivePacket(s})  =  Pending(s)  and  ~lnS4(ReceivePacket(s)) 
and  Pending(Retransmit(s))  =  Pending(s)  and  '•lnS4(Retransmit(s)) 
and  Pending(LosePacket(s)>  =  Pending(s)  and  ~lnS4(LosePacket(s)) 
and  Pending(LoseAck(s))  =  Pending(s)  and  *-lnS4(LoseAck(s»; 

theorem  ButferSpont2 , 
lnS4(s) 

imp  (Pending(ReceiveAck(s»  =  Pending(s)  and  lnS4(ReceiveAck(s)) 
or  lnSi(ReceiveAck(s})) 

and  Pending(ReceivePacket(s})  =  Pending(s)  and  lnS4(ReceivePacket(s)) 
and  Pending(Retransmit(s))  =  Pending(s)  and  lnS4(Retransmit(s)) 
and  Pending(LosePacket(s))  =  Pending(s)  and  lnS4(LosePacket(s)) 
and  Pending(LoseAck(s))  »  Pending(s)  and  lnS4(LoseAck(s)); 


111.6.  The  next-state  Transitions  for  all  Operations 

{for  the  ProtocolSend  operation:} 

theorem  SISucc  1,  { Move  from  state  SI  to  state  S2l 

InSI(s)  imp  lnS2(ProtocolSend(s,  m)); 

theorem  S2Succ1,  {No  change }  lnS2(s)  imp  lnS2(ProtocolSend(s.  m)); 
theorem  S3Succ1,{No  change }  lnS3(s)  imp  lnS3(ProtocolSend(s,  m)); 
theorem  S4Succ1,{No  change}  lnS4(s)  imp  inS4(ProtocolSend(s,  m)); 


{for  the  RecelvePacket  operation:} 

theorem  SfSucc2,  {No  change}  lnSl(s)  imp  )nS1(ReceivePacket(s)); 

theorem  S2Succ2,  {No  change,  or  move  from  state  Si  to  state  S3} 

lnS2<s)  imp  lnS2(ReceivePacket(s))  or  lnS3(ReceivePacket(s)): 

theorem  S3Succ2,  {No  change }  lnS3(s)  imp  lnS3(ReceivePacket(s)); 
theorem  S4Succ2,  {No  change}  inS4(s)  imp  lnS4(RecelvePacket(s)); 
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(lor  the  ReceiveAck  operation.} 

theorem  SlSucc3,  {No  change}  lnSl(s)  imp  lnSl(ReceiveAck(s)); 
theorem  S2Succ3,  {No  change}  lnS2(»)  imp  lnS2(ReceiveAck(s)); 
theorem  S3Succ3, {No  change}  lnS3<s)  imp  lnS3(ReceiveAck(s)); 


theorem  S4Succ3,  {No  change,  or  move  from  state  S4  to  state  £1) 

lnS4(s)  imp  lnS4(ReceiveAck(s))  or  lnS1(ReceiveAck(s)); 


(lor  the  Deliver  operation-.} 

theorem  SlSucc4,  {No  change)  InSI(s)  imp  lnSl(Deliver(8)); 
theorem  S2Succ4,  {No  change}  lnS2(s)  imp  lnS2(Deliver(s)); 
theorem  S3Succ4,  {No  change}  lnS3(s)  imp  lnS4(Deliver(s)); 
theorem  S4Succ4,  {No  change}  lnS4(s)  imp  lnS4(Deliver(s)): 


(for  the  Retransmit  operation:} 

theorem  SlSuccS,  {No  change}  lnS1(s)  imp  lnSl(Retransmit(s)); 
theorem  S2SuccS,  {No  change}  lnS2(s)  imp  lnS2(Retransmit(s)); 
theorem  S3Socc5,  (No  change}  lnS3(s)  imp  lnS3(Retransmit(s)): 
theorem  $4SuccS,  {No  change}  lnS4(s)  imp  tnS4(Retransmit(s)); 


(for  the  LoseAck  operation:} 

theorem  Sf Succ6,  (No  change}  lnS1(s)  imp  lnSl(LoaeAck(a)); 
theorem  S2Succ 6,  {No  change}  lnS2(s)  imp  lnS2(LoaeAck(s)); 
theorem  S3Succ6,  {No  change}  lnS3(s)  imp  lnS3(LoseAck(s)); 
theorem  S4Succ 6,  {No  change}  lnS4(s)  imp  lnS4(LoaeAck(s)); 


{for  the  LosePacket  operation:} 

theorem  SlSucc7,  {No  change}  lnS1(s)  imp  lnSl(LosePaeket(s)); 
theorem  S2Succ7.  {No  change}  lnS2(s)  imp  lnS2(LosePacket(s)); 
theorem  S3Succ7.  {No  change}  lnS3(s)  imp  lnS3(LoeePacket(s)); 
theorem  S4Succ7,  (No  change}  lnS4(s)  imp  lnS4(LosePacket(s)); 
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APPENDIX  IV 

IMPLEMENTING  PROCEDURES  AND  ASSERTIONS 


IV.  1 .  Asserted  Procedures  for  the  Sender 

procedure  Sender(HI  SenderToRecelver, RecelverToSender:  Medium); 

{This  Is  an  environment  for  the  send  opsrstlons  ProtocolSend  and  SandarT layout . 

It  has  no  body  and  no  assertions.} 

HI  Ponding:  QuauaOf Packet;  HI  Sant:QuauaOfMossaga;  HI  SSN:B1t; 

arocadura  Protocol Send(m: Massage;  var  success :Boolaan) 

lmport*(var  Sant:QuauaOIMassaga;  var  SandarToRacalvar:  Matlum;  var  Panting:  OuauaOlPaekat;  SSN:  BIO; 
post  PSPostlm,  success.  Sant,  Sant',  SandarToRacalvar,  SandarToRacalvar',  Panting,  Panting',  SSN); 

{does  a  ProtocolSend(p.m) ;  sets  success  bit  If  are  did  something.  Note 
that  RecelverToSender  is  not  Imported.) 
baoln  {ProtocolSend} 
it  Empty (Pending)  then 
begin: 

Pending:*  que(MakePacket(m.SStt) ) ; 

SandarToRacalvar: ■  Transm1t(SenderToRece1var ,Front( Pending) ) ; 
success:*  TRUE; 

Sent:*  Add(Sent,  m); 
end 

Hit  success:*  FALSE; 
end  {ProtocolSend}; 


procedure  SandarT imaout 

Importslvar  SantarToRacalvar.RacalvarToSantar:  Uadium-, 
var  Panting:  OuauaOlPaekat;  var  SSN:  Bit): 
post  STPoatfSantarToRacalvar,  SandarToRacalvar',  RacalvarToSantar, 

RacalvarT oSantar '.  Panting,  Panting',  SSN,  SSN'); 

{Performs  a  Retransm1t(Rece1veAck(p) )} 
begin  {SenderTImeout} 

it  SeqMatch( RecelverToSender, SSN)  {Includes  test  for  Empty} 
then  {get  a  valid  Ack} 
begin: 

Pend  1 ng : *Remove( Pending ) ; 

SSN:*  -SSN; 
lM; 

RecelverToSender  :■  Recelve(RecelverToSender); 
it  -Empty(Pendlng)  theq 

SandarToRacalvar  :*  Transm1t(SenderToRece1ver,Front(Pend1ng)); 
end  {SenderTImeout}; 

procedure  InltSender 

Imports  (var  Panting:  OuauaOlPaekat;  var  SSN:Blt); 

post  ISPost(Sant,Panting,SSN); 

begin 

Sent:*  NearQueueOf Message; 

Pending:*  NearQueueOf  Packet; 

SSN:*  InltlalSequenceNumber ; 

Hit  {InltSender}; 

begin  {Sender  has  no  body};  and: 


mmrnm* 


lab*-- 


.  ..  V  ■  ««*»*'**••- 
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IMPLEMENTING  PROCEDURES  AND  ASSERTIONS 


IV. 2.  Asserted  Procedures  for  the  Receiver 

procedure  Recalverlvar  SenderToRecelver ,  RecelverToSender.  Medium); 

var  Out:  QueueOfMessage; 
var  RSM:B1 t ; 

var  RecelverBuffer:  QuauaOf Packet ; 
procedure  RecelvePacket 

importstvar  SenderToReceiver.RecefverToSender:  Medium;  var  RSN:  BH;  var  Rec alvarBuffar:  QueuaOfPackat); 
post  RPPostf RacelvarBuller,  RacalvarBuffar',  SenderToRecelver,  SenderToRecelver', 

RecelverToSender,  RecelverToSender',  RSN,  RSN'); 

{Doesn't  deliver,  just  places  In  RecelverBuffer.  Only  Acks  after  delivery} 
begin 

If  SeqMatch(SenderToRecelver.RSN)  then 
begin 

{Something  we  were  waiting  for.  Accept,  prepare  to  deliver. 

Won't  Ack  until  delivered} 

RSN  :•  -RSN; 

RecelverBuffer  :*  que( Front(SenderToRecelver) ) ; 
end 

else  If  SeqMatch(SenderToRecelver.-RSN)  and  Empty(RecelverBuffer)  then 
{Having  delivered,  we  ACK  when  requested  for  the  last  packet} 
RecelverToSender  :•  Transm1t(Rece1verToSender. 

Front(SenderToReceiver) ) 
end:  {that's  all  for  RecelvePacket} 


procedure  Deliver 

importslvar  Out:  OueueOIMessage;  var  RecelverToSender;  Medium: 
var  RacalvarBuffar:  QueuaOfPackat); 

post  DPostfOut,  Out’,  RacalvarBuffar,  RacalvarBuffar',  RacaivarToSandar, 

RecelverToSender  '); 

begin 

11  -Empty (RecelverBuffer)  then 
begin 

Out  :»  Out  Add  Text(Front(Rece1verBuffer)) ; 

RecelverToSender:*  Transm1t( RecelverToSender,  F ront( RecelverBuffer) ) ; 

RecelverBuffer:*  NewQueueOf Packet: 

end: 

end:  fend  of  Deliver} 
procedure  InltRecelver 

Imports  (var  RSN:BH;  var  RacalvarBuffar:  QuauaOtPackat); 

post  IRPost(Out,RacaivarBuffar,RSN); 

begin 

Out:*  NewQueueOf Mas sage; 

RSN:*  InltlalSequenceNumber; 

RecelverBuffer:*  NewQueueOfPacket; 
end  {InltRecelver}; 


begin:  {Receiver  has  no  body}  end : 


ASSERTED  PROCEDURES  FOR  THE  RECEIVER 


IV.3. 

defin* 


define 


define 


define 


define 


define 


Definitions  for  the  Assertions 

DPost(sent'  .sent, rbuf  , rbuf  ,rs'  ,rs) 
ell  s(  Recel verVarsMatch( s , sent , rbuf  .SenderToRecei ver( s ) , rs ,RSN( s) ) 
imp 

Recel verVersMatch(Del fver(s) , sent ' .rbuf' .SenderToRecei ver(s) . 
rs'.RSN(s))); 

RPPost(rbuf ' , rbuf  ,sr*  .sr.rs'  .rs.rsn'  ,rsn)  ■* 
all  s(  ReceiverVarsMatch(s,Rece1ved(s) , rbuf , 
sr.rs. ran) 

Imp 

Rece1verVarsMatch(Rece1vePacket(s).Received(s),rbuf ' , 
sr' .rs' ,rsn’ )); 


IRPoat( out. rbuf ,rsn)  «• 

some  sr.rs(  ReceiverVarsMatch( Initial IzeProtocol . 

out, rbuf .sr.rs. ran)); 

STPost(sr' .sr.rs' .rs.pend' .pand.ssn' ,ssn) 
all  s(  SenderVarsMatch(s,Sent(s),pend,sr,rs,$sn) 

Imp 

SenderVarsMatch(Retransmit(ReceiveAck(  s)), 

Sent(s) .pend'  ,sr' , rs' ,ssn' )); 

PSPosf(msg.succ.sent' .sent.sr' .sr.pend' .pend.ssn)  *« 
all  s(  SenderVarsMatch(s. sent. pend, sr.RecelverloSender(s).ssn) 
imp 

SenderVarsMatch ( Protocol Send( s.msg ) . 

sent' .pend' ,sr' .ReceiverToSender(s).ssn)) 
and  succ  *  Empty(pend); 

ISPost(sent, pend.ssn)  ** 
some  sr.rs( 

SenderVarsMatch( Initial IzeProtocol. sent, pend, sr.rs.asn)); 
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IV. 4.  Context  in  Which  the  Assertions  are  Defined 

typ«  ABContext; 


declare  s.s' .sl.sZ 
declare  msg 

declare  sent, sent' .out, out' 
declare  qp, pend. pend' .rbuf .rbuf ' 
declare  sr.sr'  .rs.rs'  ,s2r,r2s 
declare  rsn.ssn.rsn’ ,ssn' 
declare  b.succ.succ' 


:  ABProlS ; 

:  Message ; 

:  QueueOIMessage ; 
:  QueueOtPacket ; 
■.Medium-, 

-.Bit; 

:  Boolean; 


interface  SenderV«rsMatch(  s .  sent ,  pend ,  sr ,  rs ,  ssn ) , 

Rece1verV«rsMetch(s .out , rbuf , sr , rs , rsn) , 
Se1ectorsMatch( s , sent , out . pend , rbuf , sr , rs , ssn , rsn ) , 
SeqMatch(sr.blt), 

Empty  (qp):  Boolean; 


define  SenderVarsMatch(s. sent. pend. sr.rs, ssn)  •• 

Set ectorsMatch(s, sent , Recelved(s) , pend, Receive rBuffer(s)  ,sr,  rs  .ssn.RSN(s) ) , 

Rece1verVarsMatch( s ,out . rbuf , sr, rs . rsn)  »» 

Se1ectorsMatch(s.Sent(s) , out, Pend 1ng(s) ,rbuf .sr.rs,  SSN(s), rsn); 

define  Se1ectorsMatch(s. sent, out. pend. rbuf .s2r,r2s, ssn. rsn)  •• 

sent  •  Sent(s)  and 
out  •  Recelved(s)  and 
pend  •  Pendlng(s)  and 
rbuf>  RecelverBuffer(s)  and 
s2r  •  SenderToRecelver(s)  and 
r2s  «  RecelverToSender(s)  and 
ssn  •  SSN(s)  and 
rsn  •  RSN(s); 


axiom  SeqNatch(plctbuf ,1)  «• 

not  Empty (pktbuf)  and  Seq(Front(pktbuf ))  •  1; 

define  Empty(qp)  ••  qp*NewQueueOf Packet; 

interface  PSPost(msg.succ,sent' . sent, sr'  ,sr, pend' , pend, ssn), 

STPost(sr' .sr.rs' ,rs, pend' .pend, ssn' , ssn), 
ISPost(sent.pend.ssn) , 

RPPost(rbuf ’ .rbuf ,sr' .sr.rs' .rs.rsn' .rsn), 
DPost(sent' . sent, rbuf .rbuf ,rs' ,rs), 

IRPost(out,  rbuf ,  rsn)  -.Boolean; 

note  the  assertion  definitions  go  here; 

end  {ABContext}; 


*•(*, 
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